Urr... slight correction. abortTransaction() doesn't clear the cache, but this is easy to workaround by just calling broker.clearCache() after broker.abortTransaction().
-----Original Message----- From: Lance Eason Sent: Friday, March 14, 2003 2:49 PM To: 'OJB Users List'; '[EMAIL PROTECTED]' Subject: RE: Transactional isolation at the object layer The combination of the latest code in CVS and using ObjectCachePerBrokerImpl gives me perfect isolation. :-) - two different brokers return different object instances for the same identity - the same broker returns the same object instance for multiple calls with the same identity within a transaction - the same broker returns the same object instance for calls in subsequent transactions as long as the earlier transactions were committed - the same broker returns different object instances for calls in new transactions after a transaction is aborted - once the broker is returned to the pool through close() it's cache is cleared I'm a happy camper. ObjectCacheDefaultImpl still manages a static map under the covers so with it in place there is still only one global cache and no isolation. -----Original Message----- From: Thomas Mahler [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2003 2:05 PM To: OJB Users List Subject: Re: Transactional isolation at the object layer Hi all, I took Lance's code snippet an rewrote it as a testCase: /** * This test checks if the caches of two different brokers are properly isolated. * changes made to an object in tx1 should not be visible in tx2 ! */ public void testCacheIsolation() throws Exception { Object[] pk = new Object[] { new Long(42)}; Identity oid = new Identity(Article.class, pk); GUID guid = new GUID(); PersistenceBroker broker1 = PersistenceBrokerFactory.defaultPersistenceBroker(); broker1.beginTransaction(); Article a1 = (Article) broker1.getObjectByQuery(new QueryByIdentity(oid)); String originalName = a1.getArticleName(); a1.setArticleName(guid.toString()); // start a second transaction PersistenceBroker broker2 = PersistenceBrokerFactory.defaultPersistenceBroker(); broker2.beginTransaction(); Article a2 = (Article) broker2.getObjectByQuery(new QueryByIdentity(oid)); assertEquals(guid.toString(), a1.getArticleName()); assertEquals(originalName, a2.getArticleName()); // fails! assertNotSame(a1, a2); // fails! broker1.commitTransaction(); broker1.close(); broker2.commitTransaction(); broker2.close(); } This is IMO a clear indication that the cache isolation does not work as intended! I'll check in the testCase into CVS. I hope we find the bug soon. cheers, Thomas Armin Waibel wrote: > Don't know if there some dependances to other classes > outside of the cache package.. > Give it a try. > (Or use CVS, should be stable) > > regards, > Armin > > ----- Original Message ----- > From: "Lance Eason" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]>; "Armin Waibel" > <[EMAIL PROTECTED]> > Sent: Friday, March 14, 2003 7:50 PM > Subject: RE: Transactional isolation at the object layer > > > The version is CVS is substantially different than the version that is > in db-ojb-1.0.rc1.gz and db-ojb-1.0.rc1-src.tgz, which is a good thing. > :-) I'm going to try it out do I need to pull anything besides the > cache package? > > -----Original Message----- > From: Armin Waibel [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 12:26 PM > To: OJB Users List > Subject: Re: Transactional isolation at the object layer > > > Hi Lance, > > what version of OJB do you use? > The cache package was refactored some > weeks ago. > You could use current CVS (run test cases to check > stability) or last release. > > regards, > Armin > ----- Original Message ----- > From: "Lance Eason" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Friday, March 14, 2003 6:28 PM > Subject: RE: Transactional isolation at the object layer > > > I don't seem to be getting any different behavior. Looking at > ObjectCacheFactory: > > > public class ObjectCacheFactory extends ConfigurableFactory > { > > private static ObjectCacheFactory INSTANCE = null; > > private ObjectCache CACHE = null; > > public static ObjectCacheFactory getInstance() > { > if (INSTANCE == null) > { > INSTANCE = new ObjectCacheFactory(); > } > return INSTANCE; > } > > public ObjectCache createObjectCache(PersistenceBroker broker) > { > if (CACHE == null) > { > > > > There's only a single ObjectCacheFactory stored as a static instance and > it holds a single instance of a cache, so there's still only one global > cache. Shouldn't the createObjectCache method create a new cache every > time or at least one per broker? ObjectCacheDefaultImpl is already > maintaining a static map so it wouldn't have any impact on it, it would > still act as a global cache but it would mean that > ObjectCachePerBrokerImpl would work as intended. > > > > -----Original Message----- > From: Thomas Mahler [mailto:[EMAIL PROTECTED] > Sent: Friday, March 14, 2003 1:15 AM > To: OJB Users List > Subject: Re: Transactional isolation at the object layer > > > Hi Lance, > > By default OJB uses one large global cache. > To achieve proper isolation you have to tell OJB to use one cache per > Broker: > In OJB.properties you have to configure to use > org.apache.ojb.broker.cache.ObjectCachePerBrokerImpl > as objectcache implementation > > cheers, > Thomas > > Lance Eason wrote: > >>I'm using 1.0 rc1 with the PB API. I'm noticing that I don't have any > > isolation between multiple brokers when caching is enabled. For > example: > >> Object[] pk = new Object[] {new Long(42)}; >> Identity id = new Identity(Article.class, pk); >> >> PersistenceBroker broker1 = > > PersistenceBrokerFactory.defaultPersistenceBroker(); > >> broker.beginTransaction(); >> >> Article a1 = (Article) broker.getObjectByQuery(new > > QueryByIdentity(id)); > >> a1.articleName = "My article"; >> >> // start a second transaction >> PersistenceBroker broker2 = > > PersistenceBrokerFactory.defaultPersistenceBroker(); > >> broker2.beginTransaction(); >> >> Article a2 = (Article) broker.getObjectByQuery(new > > QueryByIdentity(id)); > >> // a2 is another reference to the same Article as a1 >> a2.unit = "kg"; >> >> broker2.abortTransaction(); >> >> broker.store(a1, ObjectModificationDefaultImpl.UPDATE); >> broker.commitTransaction(); >> >> broker2.close(); >> broker.close(); >> >>The changes that I made on the aborted broker2 transaction end up > > getting persisted on the broker1 transaction because they're sharing the > same object reference. Similarly changes made on other transactions are > visible even before they're committed. In general it doesn't look like > I have any transactional isolation if caching is turned on. I guess my > gut expectation was that caches would be broker specific and there would > be communication between caches to coordinate invalidations on updates > and deletes. > >>So how do other people deal with this? I had thought maybe I could > > manage two jdbc-connection-descriptors pointing to the same database, > one with a cache used only for reads and another with caching turned off > used for updates but it looks like the caching policy is global not on a > per descriptor basis. Am I missing something obvious? > > > > > --------------------------------------------------------------------- > 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] > > > --------------------------------------------------------------------- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
