0

We are looking at db40 for a high volume e-commerce website using Java on the server side. Concurrency and transactional support is very important to us. When a customer purchases an item we need to lock the product and customer objects to update inventory and customer order history, respectively, in a single transaction. Is this possible with db4o? I want to make sure it support multi-object transactions.

user646584
  • 3,621
  • 5
  • 25
  • 27

2 Answers2

1

There are already similar questions here, like this one. And my answer is more or less the same.

About the high volume e-commerce website: db4o was never build as a high volume, big database but rather for embedded use cases like desktop and mobile apps. Well it depends what a 'high volume' means. I assume that it means hundreds or concurrent transactions. Thats certainly out of scope of db4o.

Concurrency and transactional support: The db4o core is still inherently single threaded and therefore can only serve a small amount of concurrent operations. db4o supports transactions with the read committed isolation. That means that a transaction can only see the committed state of other transactions. In practice thats a very weak guarantee.

To your example: you can update the purchase with the product and consumer in one transaction. However another transaction could update any of these objects and commit. Then a running transaction which already has read some objects might does calculations with the old value and stores it. So the weak isolation 'taints' your state. You could use locks to prevent that, but db4o hasn't any nice object-locking mechanism. And it would decrease the performance further.

All in all I think you probably need a 'larger' database, which has better support for Concurrency and transaction-handling.

Community
  • 1
  • 1
Gamlor
  • 12,978
  • 7
  • 43
  • 70
  • The core is single-threaded? Does that go for Versant VOD as well, which is the big brother of db4o? I find that hard to believe. If it's single threaded at the core, that would mean simple reads have to wait in line for other reads to execute. Where exactly is the 10x performance over RDBMS coming from? – user646584 Mar 24 '11 at 20:17
  • Of course that's not true for VOD. I stated the current state for db4o. VOD is another beast and supports all these features – Gamlor Mar 24 '11 at 21:41
  • Being fairly weak in database theory, I'm interested to read more about better isolation schemes than 'read committed isolation'. Can you point to some information of how 'larger' database handle this better? I had a search but can't find much. Maybe you can supply some key words at least. – Sam Stainsby Mar 26 '11 at 01:27
  • @user646584 The extra performance doesn't come from it's concurrency capabilities but the speed of complex object persistence. See: http://www.polepos.org – German Apr 08 '11 at 16:28
0

It sounds like you need to use db4o semaphores.

Sam Stainsby
  • 1,588
  • 1
  • 10
  • 19
  • Certainly possible. But to get a fine grained locking right is hard and a lot of work. And it makes the scaling aspect even worse. At that point I think you should pick a 'larger' database which supports such things much better. – Gamlor Mar 25 '11 at 11:53