Re: [castor-dev] [Castor_JDO] multithreaded environment and CASTOR JDO based on last mail thread

[bryan davis]

I'll give it a shot...    I'm developing an app that uses struts/castor and I ran into a similar issue.  I ended up building a pooling class which made sure that any time a given thread needed a Database, it got the same instance.  This made things simpler by not having to pass the database object in between objects that were enlisted to do work during a given request.  To handle commit/rollback I modified the pool so that it returned a wrapper class that extends Database such that begin, commit, rollback, etc. don't operate on the underlying database until the appropriate time.  The actual commit/rollback, etc. is handled by a RequestProcessor that finalizes any database operations after the action has completed. This gives a primitive form of container managed transactions and isolates a lot of the nastiness of making sure you can do database operations without having to worry if something else on the thread has already opened or closed a transaction.  I'll be happy to share what I've got so far if anyone wants it.   --bryan ----- Original Message ----- From: Harshal D To: [EMAIL PROTECTED] Sent: Friday, March 28, 2003 10:41 AM Subject: Re: [castor-dev] [Castor_JDO] multithreaded environment and CASTOR JDO based on last mail thread Any takers for this? I just want to validate my code - that I'll be posting with an online article. I hope that way this question will not need to answered again and again. I know it has been answered earlier, but the mail achieves do not take it to conclusion.   Thanks in advance, Harshal  Harshal D <[EMAIL PROTECTED]> wrote: Hi,   While trying to decide a strategy for use of CASTOR in a heavily concurrent web app,  I referred to the mail thread at: http://www.mail-archive.com/[EMAIL PROTECTED]/msg10198.html   Here Bruce says:   �Let's say that you have a threaded client that kicks off, say, ten > SR>threads that all use Castor, each of which grabs a Database object and > SR>each begins a transaction. Castor does not keep track of who is using > SR>what Database object so when one of the threads (clients) commits its > SR>transaction, Castor just commits the closest open transaction. This �      SR>may or may not be the correct transaction to commit.�   The part that is confusing to me � �Castor does not keep track of who is using what Database object�   Does this mean if 10 separate programs all use the same JDO instance but call getDatabse() and perform totally un related work � will still face the same problem? That is CASTOR will not know which database object to commit & close ? Even if �database object� is a local variable ?   Can any one! please comment ?     In my case I have a singleton that ensures there is only one JDO instance.   My client code looks like: { // The JDOObject is sort of a factory that returns the only JDO //instance. Every client gets a separate databse object mySQLDB=  JDOObject.getDatabase();   //Now I start the TXN   mySQLDB.begin();   // query and get results � do updates   mySQLDB.commit(); mySQLDB.close();   }   I am using STRUTS and this code appears in one Action class. I can synchronize the entire piece of code inside the braces ( �{�). But this exact similar code will be there in other Action classes. They may be querying updating different tables all together.  If CASTOR just closes the �closest open transaction� � how will this affect?   THANKS A LOT for your help . Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop! Do you Yahoo!? Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!