from ObjectsAndDataAreSeparate, CostinCozianu wrote:

''And with respect to concurrency algorithm, if they claim they have multi-version concurrency control what conflicts do they detect? Only a write-write situation is a conflict in Gemstone? I also asked RandyStafford about that but he's shy to respond.''

I've had the pleasure to speaking to RandyStafford on the phone. He's anything but shy! I mean that in the best way. He's in a much better position to answer GemStone's concurrency scheme than I am, but I'll take a stab at it and somebody can fix my mistakes. I've never been shy about showing off my ignorance (it's the thing I'm most proud of!)

As the default concurrency mechanism, GemStonej will automatically detect write-write conflicts. By virtue of MultiversionConcurrencyControl, that is the only conflict that can exist. There are no such thing as read-read conflicts. Read-write conflicts are avoided due to the versioning scheme. Two concurrent transactions start at the same time, a read transaction and a write transaction (note that you don't have to explicitly designate which type a transaction will be, all transaction start out as read transaction and GemStonej will 'promote' it to a write transaction if it modifies an object's state). Both will have obtain a view of the datastore when they start. The read transaction will see all objects as they existed at its start. The write transaction will have its private view of the datastore updated as it proceeds. The read transaction will complete without conflict (subject to implementation issues, see below) and the write transaction will complete subject to no other transaction modifying any of the same objects. This provides for ACID transactions.

Gemstonej read transactions will fail if the view of an object at transaction start time is unavailable or because of a locking issue (see below). I know that JydJavaPersistenceEngine has an implementation limitation where, in some cases, an object's version at the start of a transaction will be unavailable and therefore a read transaction will fail on commit. 
As an aside, Oracle has a similar limitation.

''And if only the earliest transaction is allowed to win, and the others are aborted, what if a particular workload pattern does not favour this particular policy (any valid concurrency control policy is a design trade-off that might suite particular class of applications but not others), what do you optimize then?''

At the application developer's option, she can use GemStonej's locking service. You can request read locks, write locks, or exclusive locks on any given object or set of objects.

Read locks guarantee that no other transaction will acquire a write or exclusive lock on that object nor will another transaction commit if it modified the object.

Write locks guarantee that no other transaction will obtain any kind of lock on that object nor will another transaction commit any change to that object.

Exclusive locks prevent any other transaction from obtaining any lock on that object and will cause any other transaction to fail if it reads or writes that object.

I hope this clears things up.

--MarkAddleman

Well, it clears a little bit but not all. This is what I already knew from the previous discussion but is far from being enough. Just to assert that ''by virtue of Multi Version Concurrency Control write-read conflict does not exist'', this is just not true. I ''assert'' that JydJavaPersistenceEngine is right here, and Gemstone might exhibit a logical problem, or just have taken a shortcut from theory, based on practical heuristics that such problems are rare. 

''Actually, the first version of what I wrote included a statement that GemStonej might fail a read transaction. Unfortunately, I couldn't quickly substantiate from the docs (the docs are one of my GemStoneGripes) and thought I must be confusing it with JydJavaPersistenceEngine. To be totally honest, I can neither confirm nor deny that GemStonej could fail a read transaction because an early enough version of an object doesn't exist.''

The cases are well documented in the online paper that I refer to in ObjectRelationalImpedanceMismatchLinks.

Oracle uses a similar scheme to what is presented here, although slightly ''less optimistic'', guaranteeing that in the presence of conflicts you'll have very few transactions aborted. Gemstone , having an ''emphatically'' optimistic policy has a chance of being a little better than Oracle for workloads that exhibit very low concurrency, but the minute concurrency starts being significant I assert that according to theoretical view on this subject, Gemstone might suffer quite a bit from having to abort transactions. 

The problem is I am not experienced in GemStoneJ , so even if I know a bit about concurrency control issue I can't guess what exactly happens , and the Gemstone site doesn't give me free access to the product documentation, unlike virtually all serious database products. Maybe you can help me further. -- CostinCozianu

''I think OODB's are converging on relational db services. The isolation level of a transaction is an important consideration. W-W isolation isn't good enough. Explicit locking is good but it is primitive. More intelligent and performant locking schemes are standard in rdBs. In time I suspect the OO data handling code will look remarkably like SQL :). --RichardHenderson.''
----
''the Gemstone site doesn't give me free access to the product documentation, unlike virtually all serious database products''

That's a low blow, Costin, and irrelevant to any of this discussion. I'll note that it was only within the last couple of years that IBM placed Db2's documentation on the web. It happens that GemStone's support site is available to everyone if you register (http://support.gemstone.com). You'll find that the documentation is a bit scattered and occasionally dense, but the information you need is generally in there. I'm looking through my docs and will get back to you with the official answer if I can find it.

It's not a low blow, it is merely a fact. I'm not interested in blowing either GemstoneJ or GemstoneS.
Oracle also requires you registration, which is always very annoying, but what prevented me from registering at Gemstone is when they announce me that I will have access for 30 days only. Whatever, in this case, I'm not willing to give up my information and go the extra annoyance. If they are not willing to encourage independent developer review it's their marketing department problem, it's not my problem.