danch....
I think this is wonderful work and squarely adressing the speed issues of
JBossCMP.
I asked you zillions of times to send me picture and bio already :)
also I am about to check in the new version of the website (was working on
it for the past 2 days) it is FULLY JSP and runs on Tomcat/JBOSS so we will
get rid of the apache stuff. I have also updated the JBOSS CMP pages and I
want you to update those pages with the FEATURES and TODO.
Part of what RabbitHole is is to get the new recruits enrolled in the
on-going projects and your role is to recruit :)
Excellent work,
regards
marcf
|-----Original Message-----
|From: [EMAIL PROTECTED]
|[mailto:[EMAIL PROTECTED]]On Behalf Of danch
|Sent: Wednesday, June 13, 2001 8:00 AM
|To: jboss-dev; jbossCMP; Sacha Labourey
|Subject: [JBoss-dev] finder optimization round 2 checked in
|
|
|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
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
