This one time, at band camp, Sylvie Ramon said:
SR>I search, i search, and i don't found anything.
SR>I import th latest version of castor.
SR>The problem persist.
SR>
SR>How can i be sure that my web application is "thread safe ?"
SR>
SR>Is someone has any experiences on web application with castor and concurrent access
?
SR>
SR>
SR>thanks a lot.
SR>Sylvie
SR>
SR>
SR>
SR>-----Original Message-----
SR>From: Bruce Snyder [mailto:ferret@;frii.com]
SR>Sent: mar. 29 octobre 2002 20:09
SR>To: [EMAIL PROTECTED]
SR>Subject: Re: [castor-dev] [castor-dev]Pb with concurrent access on
SR>database Oracle
SR>
SR>
SR>This one time, at band camp, Sylvie Ramon said:
SR>
SR>SR>Hi,
SR>SR>
SR>SR>I have a problem and I don't understand what append.
SR>SR>
SR>SR>I work with WSAD 4.0, Oracle 8i and castor 0.9.3.9 .
SR>SR>
SR>SR>I develop an web application that read and create objects in database.
SR>SR>All is ok if I run this with one or several user in a real time.
SR>SR>
SR>SR>I try to test my web application with Opensta.
SR>SR>I store a scenario, and do an iteration on it.
SR>SR>I reduct "wait" to have intensives tests.
SR>SR>All is ok if I run ONE scenario.
SR>SR>
SR>SR>But, if I run SEVERAL scenarios ( concurrent access ) , I have some Exception,
that append randomly :
SR>SR>
SR>SR>
SR>SR>org.exolab.castor.jdo.TransactionNotInProgressException: This database is closed
SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getTransaction(DatabaseImpl.java:464)
SR>SR> at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:269)
SR>SR> at org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:287)
SR>SR> at
fr.cmc.umm.entreprise.typologieappel.MotifContactService.getFicheMotif(MotifContactService.java:236)
SR>SR> .....
SR>SR>
SR>SR>OR
SR>SR>
SR>SR>
SR>SR>java.lang.NullPointerException
SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getLockEngine(DatabaseImpl.java:196)
SR>SR> at org.exolab.castor.jdo.engine.OQLQueryImpl.create(OQLQueryImpl.java:270)
SR>SR> at org.exolab.castor.jdo.engine.DatabaseImpl.getOQLQuery(DatabaseImpl.java:439)
SR>SR> at
fr.cmc.umm.entreprise.typologieappel.MotifContactService.getListeMotifActif(MotifContactService.java:314)
SR>SR> .....
SR>SR>
SR>SR>
SR>SR>OR
SR>SR>
SR>SR>
SR>SR>org.exolab.castor.jdo.TransactionNotInProgressException: No transaction in
progress for the current thread
SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getTransaction(DatabaseImpl.java:467)
SR>SR> at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:458)
SR>SR> at org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:405)
SR>SR> at
fr.cmc.umm.entreprise.typologieappel.SousMotifContactService.getListeSousMotifActif(SousMotifContactService.java:396)
SR>SR> ....
SR>SR>
SR>SR>
SR>SR>
SR>SR>Someone has an idea ?
SR>
SR>Sylvie,
SR>
SR>In my experience, these types of problems usually occur in either a
SR>multi-threaded environment (like your concurrent accesses) or in a
SR>situation where transactions are being nested. In either case, it is
SR>unclear as to which transaction needs to be commit()ed by Castor so it
SR>closes the closest one which may or may not be correct. The solution
SR>here is to make the application more thread safe or to name each Database
SR>instance differently. I have usually chosen to make the application more
SR>thread safe so that the confusion doesn't occur.
Let's say that you have a threaded client that kicks off, say, ten
threads that all use Castor, each of which grabs a Database object and
each begins a transaction. Castor does not keep track of who is using
what Database object so when one of the threads (clients) commits its
transaction, Castor just commits the closest open transaction. This
may or may not be the correct transaction to commit. If it is the
wrong transaction that is committed, when the thread that was actually
using the transaction that was just committed attempts to commit, the
TransactionNotInProgressException is thrown with a message indicating
the problem.
The above messages do provide some info:
This database is closed - This indicates that db.close() was called
before threads were through using that particular Database object
instance.
I'll take a guess that the NullPointerException proabably is just
a biproduct of one of the other exceptions that were thrown.
No transaction in progress for the current thread - This indicates a
situation like the one I explained above. A transaction was committed
out from under the thread that was actually using it.
Does this help you understand your situation more?
Bruce
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
