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]
