> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of danch > Sent: Monday, June 25, 2001 12:17 AM > To: [EMAIL PROTECTED] > Subject: Re: [JBoss-dev] finder optimization(read-ahead) phase 3 > > > Bill Burke wrote: > > > > >> > > > > > > Can you explain this again in other words? I'm kind of > confused. Are you > > saying you don't want to have a hashMap of preloaded data per > transaction? > > But just one global cache? I think that is a bad idea. I'll > clarify more > > if this is what you mean. > > That is what I mean (for option A only!). We can also do a look aside > for option A (as you said higher up in your email) to make sure we don't > read-ahead something that's already in the cache. > > Here goes again for my rational: In option A, we own the database, so > there can be no external changes. If the data is changed by another > transaction in JBoss, it will go through JAWS load code first, so the > data will be taken out of the read-ahead before it is modified. Have I > missed something? > After thinking about this a little more, your shared read-ahead will work if you make sure you don't load the read-ahead cache with entities that are already in the EntityInstanceCache. The scenario I was thinking of. Transaction 1: 1. modify entity A Transaction 2: 2. findAll Transaction 1: 3. findAll - <causes ejbStore of A, then loads up read-ahead cache with modified A> 4. rollback - <with current codebase, A is trashed from the entity instance cache and returned to the pool.> Transaction2: 5. getA from findAll. LoadEntity finds A in read-ahead cache. Read-ahead cache has bad data. I still have a bad feeling about sharing the read-ahead cache between transactions in commit option 'A', but I can't currently find any problems with it. Bill _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
