Re: [OJB-developers] implicit locking and ODMG compliance (and JDO)

[Carl R. <ca...@db...>]

> >>  JDO does require implicit locking, and uses a class "enhancer" to make
> >>  it work. The reference implementation produces replacement java source
> >>  code for peristent classes, and so does not completely implement the
> >>  specification.
> >
> >to my knowledge, JDO does not mandate the use of the enhancer - so
> >replacement code should be inside the spec as well. The enhancement issue
> >was (and is) the subject of much debate (e.g., on TheServerSide), as you
> >probably know. But of course, in order to meet the implicit locking
> >requirement, there are not too many options...
> 
> ... and they are all ugly.


Hi all,

in my opinion implicit locking always is awfully ugly.
It may be one of the reasons for the failure of object
databases to acquire a noticeable market share in the
past. The loudest complaints I have read against object
databases, report a nice development stage and a good
running test application but dreadful fiascos, once 
multiple users started accessing the system.

I would stay away from implicit locking, no matter what
ODMG or JDO specifications suggest. Locking data during
a read process is just about the worst thing you can do.
We have achieved good results on relational systems in
the past, by using a combination of semaphores and 
fine-tuned *manually coded* row locks.

...my 2 cents.

Kind regards,
Carl
---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com