my personal version of OJB does this: clear cache at end of transaction. It's a nasty work-around that is necessary right now.
The OTM will have 2 levels of cache. Global and Editing Context. The editing context (or transaction context if you like) will contain a copy of the object that is localized to the current transaction, when that completes objects are copied back into the global cache. If the transaction rolls back, the editing context is destroyed therefore throwing out the changes. The association with the transaction is not necessarily thread-based. we can re-associated a call with the editing context using the transaction manager and hence whatever it is using to do the association. m -----Original Message----- From: Max Rydahl Andersen [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 12, 2002 12:11 AM To: OJB Users List Subject: Re: per thread caching [was: Re: Anyone up for a "challange" ? :)] This is how I at some point solved the problem in another persistence layer. This works "great" as long as one remember to cleanup the cache after the transaction is completed. If this is not done the cache can contain "leftovers" from the previous thread that might not be commited (or does OJB handles this ?) Secondly it is viable in almost any system, except for J2EE's if you read the spec - the spec does not guarantee that a given transaction/method call/bean will be executing in the same thread in all its lifetime....just for info: Most servers does run it in the same thread, but it is not guaranteed :) /max ----- Original Message ----- From: "Jens Krämer" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, September 11, 2002 1:46 AM Subject: per thread caching [was: Re: Anyone up for a "challange" ? :)] > Hi all, > > I followed this thread and thought the solution I found might be of > interest to somebody. > > I implemented kind of a 'meta cache' which holds a cache instance for > each thread. To prevent the different caches from getting out of sync I > 'hacked' PersistenceBrokerImpl.store(Object obj, boolean insert, Map > markedForStore) to tell the meta cache whenever an Object is updated. > > On commit the meta cache removes the objects corresponding to these > changed objects from the cache instances of all other threads > (to force reloading of the now committed changes). > > On rollback it removes the changed objects from the cache of the > current thread. > > I dont consider this a nice solution but maybe it's a starting point. > I also must admit I didn't try it in a production environment, but > at least a testcase with two threads seems to work ;-) > > I'll post/send the code if somebody is interested in... > > Greetings, > > Jens > > -- > Jens Krämer > [EMAIL PROTECTED] > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
