After several false starts, I've finally checked in round one of the optimizations for finder methods in JAWS (to avoid the 'n+1 database hits' problem). My simple tests show that a findAll returning 1000 instances now executes in roughly 40% to 50% of the time it used to take. To experiment with this feature add '<read-ahead>true</read-ahead>' into a finder stanza in your jaws.xml. Note that another change I've made allows specification of findAll methods in jaws.xml, so this will work for a findAll. This is currently implemented as two database accesses: one for the keys and one to load the entities. This actually de-optimizes finds where all targeted beans are in the cache! Also, I'd expect strange results if the total rowset is larger than the entities cache allows for. Implementation notes and future direction: I've added a class FinderResults to help organize and hold information neccessary to coordinate the keyset and the actual retrieved data. My intent is to add support for the deployer to specify the maximum number of entities that should be loaded at any one time (a 'page-size' setting). This, and the extension of the FinderResults interface into the invocation layer should allow us to provide 'scrollable' collections to client code. Naturally, there will be a lot of complications under the covers with that particularly when we consider the interactions between transactions, commit-option, and database access patterns. take a look, give it a try, comment, improve! P,L & GC, -danch _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-development
