Hi Matthew, Attached is the code for you to get started and for anyone else who's itching to use Oracle's update batching right away.
This implementation allows you to enable/disable update batching and set the batch size in OJB.properties. Warnings: 1. This batching implementation will not work with optimistic locking. 2. This batching implementation requires that all database work be done in the context of a PersistenceBroker transaction; i.e., at some point commit() must be called on the connection to ensure that all statements in the batch queue are sent to the database. If you use the ODMG API you should be fine... Any feedback is welcome. Cheers, Richard ----- Original Message ----- From: "Matthew Baird" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Wednesday, September 04, 2002 8:12 AM Subject: RE: metrics on batch update > could you send me the 'hacked' code, so I have a starting point? thanks > Matthew > > -----Original Message----- > From: Richard Beauchamp [mailto:[EMAIL PROTECTED]] > Sent: Wed 9/4/2002 12:23 AM > To: OJB Users List > Cc: > Subject: Re: metrics on batch update > > > > Hi Matthew, > > > ----- Original Message ----- > > From: "Matthew Baird" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Wednesday, August 14, 2002 12:08 PM > > Subject: metrics on batch update > > > > <snip> > > > Anecdotal evidence says we could get a 40% improvement in performance on > updates/inserts > > due to lowered RPC's on the db. If that is true, a medium-major refactoring > would be > > warranted. > > I just refactored some classes in OJB v0.9.5 to support batch > inserts/updates/deletes using Oracle's update batching. I then ran > org.apache.ojb.broker.PerformanceTest which inserts/updates/deletes 10,000 rows. > The tests generated these results: > > Scenario #1: No batching/No prepared statement caching (as exists in v0.9.5) > insert - 83 sec > update - 82 sec > delete - 63 sec > > Scenario #2: No batching/Prepared statement caching (49% improvement over > scenario #1) > insert - 45 sec > update - 40 sec > delete - 31 sec > > Scenario #3 Batching/Prepared statement caching (83% improvement over scenario > #1) > insert - 12 sec > update - 13 sec > delete - 13 sec > > > Looks like a refactoring is certainly warranted against the Oracle platform. > > -Richard > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -------------------------------------------------------------------------------- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
OracleBatchUpdates.zip
Description: Zip compressed data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
