Sylvie, Can you show us the code that creates a new instance of JDO inside of the servlet, as this seems to be the problem. In your web app, you should only ever create one instance of Castor JDO at any time ... for example in a separate servlet that would only be executed at startup of the container.
Werner Sylvie Ramon wrote: > 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 ----------------------------------------------------------- If you wish to unsubscribe from this mailing, send mail to [EMAIL PROTECTED] with a subject of: unsubscribe castor-dev
