Re: [OJB-developers] Re: OJB-ODMG does[n't] support implicit locking

[Thomas M. <tho...@ho...>]

Hi Doug,

Doug Currie wrote:

> TM> Here is my argument why OJB still meets the requirements:
> 
> TM> During tx commit OJB automatically upgrades Locks for objects that only
> TM> have a READ lock. So we obtain WRITE locks implicitely for modified
> TM> objects. ODMG does not specify at which point in time the WRITE lock is
> TM> to be acquired!  ;-)
> 
> I might buy this if
> a) the READ locks were obtained implicitly, and


READ locks are obtained implicitely during OqlQueryImpl.execute() and 
(after the latest bug fix also) in DatabaseImpl.lookup(...).
But: for "read-uncommited" no LockEntries are placed into the LockMap.
The semantics of "read-uncommited" as implemented now is "you are always 
allowed to read". Maybe we have to modify this semantics?


> b) the isolation mode is read-uncommitted


Hmm. If you are NOT using "read-uncommited" and there is no READ-lock in 
the LockMap it must be a bug! Which isolation level are you using for 
class Article ?


Maybe we need different semantics for the isolation levels? Did you have 
a look at my doc concerning the LockManager? It contains a table 
demonstrating the behaviour of all isolation levels currently implemented.


> 
> Neither of these is true in my example.
> 
> TM> One of the next things we implement is optimistic locking (similar to
> TM> the TOPLink approach).
> 
> Yes, this would be nice; a version number or timestamp would be needed
> on each object to see if the current version on disk matches the
> version modified by the transaction.
> 


Jakob just posted his Optimistic locking solution to the developer list 
I will integrate it asap.


> TM> If an application uses optimistic locking your argument is not longer
> TM> valid, as collision-detection is delayed until RDBMS access during tx
> TM> commit.
> 
> The problem remains that transaction isolation is violated since an
> object can be modified by multiple transactions since there is only
> one version in the cache.


I believe this problem could be solved if we reconstitute the original 
state of objects during tx.abort().
Your /*6*/ would not return a modified value then!

 JDO fixes this by having many copies of the
> same object in memory, one per writer. This breaks java object
> identity, so they invented "JDO identity."
> 
> TM> So I cannot see why OJB should not be compliant to the implicit locking
> TM> feature!
> 
> As long as there are versions/timestamps and many copies of the
> same object in memory, one per writer.
> 
> TM> There are also some "lazy" implementors (e.g. Objectivity) that require
> TM> the user to place locking code into getter and setter methods.
> 
> TM> I think this is a valid approach, as the intrusion into user code is
> TM> minimal.
> 
> It is worth considering.
> 
> TM> Currently I favour the following implementation strategy for OJB-JDO:
> TM> Reuse (or make a clearroom rewrite) of those aspects of SUNs JDO
> TM> Reference Implementation (RI), that are related to Lifecycle,
> TM> Codeenhancement etc.
> 
> The current RI enhancer generates source code, and is non-compliant.
> 
> TM> And simply write a com.sun.jdori.StoreManager implementation that
> TM> parallels the com.sun.jdori.fostore.FOStoreStoreManager but uses a OJB
> TM> PersistenceBroker to perform persistence operations.
> 
> I suspect you may also want to consider:
> - using some of the current odmg locking stuff
> - using some of the current odmg ObjectEnvelope stuff
> - making ojb.broker's repository.xml syntax more compatible with jdo
>   (or adding an alternate syntax there)
> 


Yes, but only in a second step.
The first step will be to plugin a PersistenceBroker based StoreManager 
into JDORI.
There are many people that doubt that a OJB-JDO implementation can be 
build with relatively few efforts that I think it's good to have a 
working prototype as a source of inspiration.

cu,
Thomas


> Regards,
> 
> e
> 
> 
> _______________________________________________
> Objectbridge-developers mailing list
> Obj...@li...
> https://lists.sourceforge.net/lists/listinfo/objectbridge-developers
> 
> 
> 
>