Just got a reply from Thomas Mahler regarding ODMG and optimistic locking in
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=14647
(repeated here).
I just wanted to confirm that optimistic locking is also supported in OJB/ODMG.
In the early days (before 2002) the ODMG transaction manager did only provide
pessimistic locking. But even then we did not use any pessimistic locking on the
RDBMS, but used our own locking engine.
Since about two years it is now possible to use the Optimistic Locking as
implemented by the OJB PersistenceBroker in OJB ODMG applications too.
In the class-descriptors of your persistent classes you have to set the
isolation-level attribute to "optimistic". You can also do this globally on the
descriptor-repository level.
But when using ODMG in a cluster, i.e. with OsCache, does this statement still hold
true?
Thanks,
Mark
----- Original Message -----
From: "Armin Waibel" <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Thursday, September 16, 2004 5:09 AM
Subject: Re: Is there any update on the following post about cache configurations?
> Hi Mark,
>
> > It seems that 1 and 2 are provided by the ObjectCacheDefaultImpl in
> the odmg
> > layer with pessimistic locking in a non-clustered configuration.
> This is the
> > configuration we are running now. It looks like TransactionImpl.abort
> > eventually calls StateOldDirty.rollback that calls removeFromCache.
> > Is this true?
> >
>
> yep nearly. ObjectCacheDefaultImpl does not prevent "dirty reads" if you
> work on the same instance of an cached object. E.g. thread 1 lookup
> object A, OJB found A in cache and return, thread 1 get write lock on A.
> Now thread 2 lookup the same object, the cache return the same instance
> (no copy, same JVM) of A. If you know change fields in A, thread 2 will
> see these changes (because of the same instance).
>
>
> > But what about a clustered configuration with odmg?
> >
>
> In a cluster you have to use a distributed cache (e.g. OsCache based)
> http://db.apache.org/ojb/docu/guides/objectcache.html#ObjectCacheOSCacheImpl
>
> and additionally you need distributed pessimistic locking. Currently we
> have a servlet based solution, sorry no detailed docs only notes in
> OJB.properties file
> http://db.apache.org/ojb/OJB.properties.txt
>
> regards,
> Armin
>
>
> Mark Neighbors wrote:
> > Is there any update on the following post about cache configurations?
> >
> > http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=1601279
> >
> > Excerpt:
> >
> > > We need a cache that is:
> > > 1. one cache per server ( so that multiple threads see the objects,
> > > cached by another thread)
> > > 2. transaction-safe ( if thread a in Transaction TXa create a new
> > > object, thread b in Transaction TXb shouldn't see the ne object before
> > > TXa is committed)
> > > 3. nice to have is clustering support.
> > >
> > > It seems that 1 an 3 is delivered by OScache. But is OSCache
> > > transactions-safe? Which cache supports 1 and 2 ???
> >
> > Sorry currently none.
> > This is on the roadmap for 1.1. We want to implement a real two level
> > cache. First level will be transaction-safe and deal with given objects,
> > the second level only handle copies of given objects.
> >
> > Is there a workable configuration for odmg at this point possibly with
> > compromises?
> >
> > It seems that 1 and 2 are provided by the ObjectCacheDefaultImpl in the odmg
> > layer with pessimistic locking in a non-clustered configuration. This is the
> > configuration we are running now. It looks like TransactionImpl.abort
> > eventually calls StateOldDirty.rollback that calls removeFromCache.
> > Is this true?
> >
> > But what about a clustered configuration with odmg?
> >
> > Thanks in advance,
> > Mark
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
