Thanks for your message, Bruce.
This is more clear.
My code looks like your code.
This is stange.
Probably there is something in my code who cause the problem.
Each time the servlet is called :
- I create a new instance of JDO, and consequently a new database.
- On this database,
- i do a begin,
- i do a search on a table,
- after, on an another table,
- then I commit(), and
- i close the database.
It seems to be correct, no ???
Thanks again for your patience....
Sylvie
-----Original Message-----
From: Bruce Snyder [mailto:ferret@;frii.com]
Sent: mar. 5 novembre 2002 19:01
To: Sylvie Ramon
Subject: RE: [castor-dev] [castor-dev]Pb with concurrent access on
database Oracle
This one time, at band camp, Sylvie Ramon said:
SR>But this is not a big bug from Castor ??????
SR>I search, and i don't know how solve this problem.
SR>
SR>Can I use UserTransaction i.s.o TransactionManager ?
SR>If yes, how ?
No, this is not a bug in Castor. Just so that this is clear, Castor is NOT
a transaction manager. Castor plays the role of the cache manager. Castor
does, in fact, fake a small amount of transaction management for the
use of Castor in a stand alone environment, but this bit of transaction
management should NOT be chosen over a true transaction management
implementation (like the ones that come with app servers) whenever
possible.
However, I have written servlet based web apps (using Tomcat) that use
Castor in a standalone setting, some of which supported a high amount of
concurrency. In these situations, I usually write a startup servlet that
creates the JDO object and stores it in memory for other objects to use. I
also use long transactions in a web environment whereby a set of objects
is fetched in one transaction and is brought into the context of another
transaction using db.update(). This brings up another concern which is the
structure of each transaction. I usually try to keep each transaction in
close proximity. I don't spread a single transaction across methods or
classes (although I've worked on apps where this was done successfully,
too). In this scenario, most of my transactions look like the following:
public ArrayList getAllFoos()
{
try
{
oql = _db.getOQLQuery( "select f from org.foo f order by desc" );
...
_db.begin();
results = oql.execute();
while ( results.hasMore() )
{
foo = ( Foo ) results.next();
list.addElement( foo );
}
results.close();
_db.commit();
}
catch ( ConcurrentModifcationException cme )
{
try
{
if ( _db.isActive() )
_db.rollback();
}
catch ( Exception e )
{
log.warn( "some message: " + e.getMessage() );
}
throw cme;
}
}
public void updateFoos()
{
try
{
_db.begin();
_db.update( someFoo );
_db.commit();
}
catch ( ConcurrentModifcationException cme )
{
try
{
if ( _db.isActive() )
_db.rollback();
}
catch ( Exception e )
{
log.warn( "some message: " + e.getMessage() );
}
throw cme;
}
}
I'm not trying to dodge your questions at all. I'm actually trying
to help you as much as I can. Using Castor for developing web apps in
this manner is VERY common, and web apps usually equal concurrency. I
have absolutely no knowledge of your app and it's design. However, in
situations like yours, oftentimes the problem boils down to how it was
put together. I'm sure if you press this issue on the list, you'll get
feedback from others who will agree.
SR>-----Original Message-----
SR>From: Bruce Snyder [mailto:ferret@;frii.com]
SR>Sent: jeu. 31 octobre 2002 20:27
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>I search, i search, and i don't found anything.
SR>SR>I import th latest version of castor.
SR>SR>The problem persist.
SR>SR>
SR>SR>How can i be sure that my web application is "thread safe ?"
SR>SR>
SR>SR>Is someone has any experiences on web application with castor and concurrent
access ?
SR>SR>
SR>SR>
SR>SR>thanks a lot.
SR>SR>Sylvie
SR>SR>
SR>SR>
SR>SR>
SR>SR>-----Original Message-----
SR>SR>From: Bruce Snyder [mailto:ferret@;frii.com]
SR>SR>Sent: mar. 29 octobre 2002 20:09
SR>SR>To: [EMAIL PROTECTED]
SR>SR>Subject: Re: [castor-dev] [castor-dev]Pb with concurrent access on
SR>SR>database Oracle
SR>SR>
SR>SR>
SR>SR>This one time, at band camp, Sylvie Ramon said:
SR>SR>
SR>SR>SR>Hi,
SR>SR>SR>
SR>SR>SR>I have a problem and I don't understand what append.
SR>SR>SR>
SR>SR>SR>I work with WSAD 4.0, Oracle 8i and castor 0.9.3.9 .
SR>SR>SR>
SR>SR>SR>I develop an web application that read and create objects in database.
SR>SR>SR>All is ok if I run this with one or several user in a real time.
SR>SR>SR>
SR>SR>SR>I try to test my web application with Opensta.
SR>SR>SR>I store a scenario, and do an iteration on it.
SR>SR>SR>I reduct "wait" to have intensives tests.
SR>SR>SR>All is ok if I run ONE scenario.
SR>SR>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>
SR>SR>SR>org.exolab.castor.jdo.TransactionNotInProgressException: This database is
closed
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getTransaction(DatabaseImpl.java:464)
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:269)
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.load(DatabaseImpl.java:287)
SR>SR>SR> at
fr.cmc.umm.entreprise.typologieappel.MotifContactService.getFicheMotif(MotifContactService.java:236)
SR>SR>SR> .....
SR>SR>SR>
SR>SR>SR>OR
SR>SR>SR>
SR>SR>SR>
SR>SR>SR>java.lang.NullPointerException
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getLockEngine(DatabaseImpl.java:196)
SR>SR>SR> at
org.exolab.castor.jdo.engine.OQLQueryImpl.create(OQLQueryImpl.java:270)
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getOQLQuery(DatabaseImpl.java:439)
SR>SR>SR> at
fr.cmc.umm.entreprise.typologieappel.MotifContactService.getListeMotifActif(MotifContactService.java:314)
SR>SR>SR> .....
SR>SR>SR>
SR>SR>SR>
SR>SR>SR>OR
SR>SR>SR>
SR>SR>SR>
SR>SR>SR>org.exolab.castor.jdo.TransactionNotInProgressException: No transaction in
progress for the current thread
SR>SR>SR> at
org.exolab.castor.jdo.engine.DatabaseImpl.getTransaction(DatabaseImpl.java:467)
SR>SR>SR> at
org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:458)
SR>SR>SR> at
org.exolab.castor.jdo.engine.OQLQueryImpl.execute(OQLQueryImpl.java:405)
SR>SR>SR> at
fr.cmc.umm.entreprise.typologieappel.SousMotifContactService.getListeSousMotifActif(SousMotifContactService.java:396)
SR>SR>SR> ....
SR>SR>SR>
SR>SR>SR>
SR>SR>SR>
SR>SR>SR>Someone has an idea ?
SR>SR>
SR>SR>Sylvie,
SR>SR>
SR>SR>In my experience, these types of problems usually occur in either a
SR>SR>multi-threaded environment (like your concurrent accesses) or in a
SR>SR>situation where transactions are being nested. In either case, it is
SR>SR>unclear as to which transaction needs to be commit()ed by Castor so it
SR>SR>closes the closest one which may or may not be correct. The solution
SR>SR>here is to make the application more thread safe or to name each Database
SR>SR>instance differently. I have usually chosen to make the application more
SR>SR>thread safe so that the confusion doesn't occur.
SR>
SR>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. If it is the
SR>wrong transaction that is committed, when the thread that was actually
SR>using the transaction that was just committed attempts to commit, the
SR>TransactionNotInProgressException is thrown with a message indicating
SR>the problem.
SR>
SR>The above messages do provide some info:
SR>
SR> This database is closed - This indicates that db.close() was called
SR> before threads were through using that particular Database object
SR> instance.
SR>
SR> I'll take a guess that the NullPointerException proabably is just
SR> a biproduct of one of the other exceptions that were thrown.
SR>
SR> No transaction in progress for the current thread - This indicates a
SR> situation like the one I explained above. A transaction was committed
SR> out from under the thread that was actually using it.
SR>
SR>Does this help you understand your situation more?
SR>
SR>Bruce
SR>
--
perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
Disclaimer
This communication together with any attachments transmitted with it ('this E-mail')
is intended only for the use of the addressee and may contain information which is
privileged and confidential. If the reader of this E-mail is not the intended
recipient or the employee or agent responsible for delivering it to the intended
recipient you are notified that any use of this E-mail is prohibited. Addressees
should ensure this E-mail is checked for viruses. The Carphone Warehouse Group PLC
makes no representations as regards the absence of viruses in this E-mail. If you have
received this E-mail in error please notify our ISe Response Team immediately by
telephone on + 44 (0)20 8896 5828 or via E-mail at [EMAIL PROTECTED] Please then
immediately destroy this E-mail and any copies of it.
Please feel free to visit our website:
UK
http://www.carphonewarehouse.com
Group
http://www.phonehouse.com
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
