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

[Harshal D]

THANK YOU !!!

Its all clear now. When I read "Castor will commit the transaction on the Database object instance on which commit() is called."  - that makes me happy !

 

 Bruce Snyder <[EMAIL PROTECTED]> wrote:

This one time, at band camp, Harshal D said:

Please see my comments inline.

HD>Honestly, I did not understand this completely. But, I guess I can take a look at your code, understand it further and then discuss this.
HD> bryan davis <[EMAIL PROTECTED]>wrote: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!
op!
HD>ened 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 AMSubject: Ree: [castor-dev] [Castor_JDO] multithreaded environment and CASTOR JDO based on last mail thread
HD>
HD>Any takers for this?
HD>
HD>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.
HD>
HD>
HD>
HD>Thanks in advance,
HD>
HD>Harshal
HD>
HD> Harshal D <[EMAIL PROTECTED]>wrote:
HD>Hi,
HD>
HD>
HD>
HD>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
HD>
HD>
HD>
HD>Here Bruce says:
HD>
HD>
HD>
HD>�Let's say that you have a threaded client that kicks off, say, ten
HD>
HD>> SR>threads that all use Castor, each of which grabs a Database object and
HD>
HD>> SR>each begins a transaction. Castor does not keep track of who is using
HD>
HD>> SR>what Database object so when one of the threads (clients) commits its
HD>
HD>> SR>transaction, Castor just commits the closest open transaction. This
HD>
HD>� SR>may or may not be the correct transaction to commit.�

This statement is rather vague and not altogether clear and I apologize
for that. The fact that Castor does not track these open Database
objects is not a problem because the JVM actually handles this. What's
more, Castor doesn't just commit the closest open transaction. That's a
misstatement. Castor will commit the transaction on the Database object
instance on which commit() is called.

Most of your comments in this thread are similar to those made by Sylvie
Ramon in the following thread:

http://www.mail-archive.com/[EMAIL PROTECTED]/msg10044.html

Besides my misstatement above, are any of my other comments unclear?

HD>The part that is confusing to me � �Castor does not keep track of who is using what Database object�
HD>
HD>
HD>
HD>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 ?

I corrected my previous statement above regarding this.

HD>In my case I have a singleton that ensures there is only one JDO instance.

I have seen some applications use this. In fact, I have coded an app
that used Castor just like this in the past.

HD>My client code looks like:
HD>
HD>{
HD>
HD>// The JDOObject is sort of a factory that returns the only JDO //instance. Every client gets a separate databse object
HD>
HD>mySQLDB= JDOObject.getDatabase();
HD>
HD>
HD>
HD>//Now I start the TXN
HD>
HD>
HD>
HD>mySQLDB.begin();
HD>
HD>
HD>
HD>// query and get results � do updates
HD>
HD>
HD>
HD>mySQLDB.commit();
HD>
HD>mySQLDB.close();

The only issue I can see is if another transaction is going to be
started off of the same Database object instance, there is no need to
call close(). The call to jdo.getDatabase() is actually grabbing a JDBC
Connection object which requires a fair amount of overhead. Calling
getDatabase() and close() over and over entails a lot of resources and
I discourage doing this unless you're employing the use of a connection
pooler. See http://www.castor.org/pooling.html for more info on this.

HD>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?

As I stated above, my statement was incorrect. See my comments above.

There is no need to synchronize the entire block of code above. That's a very
wide synchronization. I would at least try to pare it down a bit if not
stopping the use of synchronization altogether in that block. But that is
dependent upon your application for which I have no knowledge. So this is your
call.

Bruce
--
perl -e 'print unpack("u30","<0G)[EMAIL PROTECTED]&5R\"F9E
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev

---

Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more