This pass is significantly different than the last, which didn't really adhere to the component contract for CMP. In my tests (with 1000 entities), these finders take 40%-50% of the time they used to. This should also resolve the problems that the original implementation had with defined finders that needed to do joins. This feature is activated by placing '<read-ahead>true</read-ahead>' in the <finder> element in jaws.xml. High points: This implementation preloads the data from the database and keeps it around. The Load operation refers to the preloaded data, if available. The preloaded data is mapped by transaction, so that what a transaction sees for data is what was in the database when the finder was called. JAWS now registers a Synchronization with the transaction to clear out the preloaded data when the transaction commits or rolls back. Finders that are invoked without a transaction active are basically lumped into one big pile right now - any access will get whatever was last preread outside of a transaction. I don't believe that we can guarentee serializable transaction isolation at this point: not without doing select for update at any rate. (Note that the select for update option won't effect the preloaded data right now). TODO: Shorten critical sections around the transaction->entity map. Use weak references of some sort for the read-ahead data (ease memory hit) clean up in CMPPersistenceManager.findEntities (I'll do this tomorrow). Get my tests into the jbosstest module. Lots of testing in intensely loaded environments! Add an upper limit setting for the number of rows to pre-load (per finder). More minor things that I'm too tired to think of at this point. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
