Thomas, I guess you are right about WebLogic OCI connection pool, just tried out BEA released WebLogic 6.1 SP1, seems the wiered problem is gone.
I am using QueryResult.hasMore(), next() pair. If every time OQL hit the database, why after I changed the records in the database externally, OQL returns wrong results (count is right, value inside the object is wrong)? And will the result update the JDO cache ? I guess it does not, after OQL results showing on the screen, if I pick up one to update through db.load() ( db.load() by id will get the object from the JDO cache ), then I got ObjectModifiedException. Maybe that is the reason. All above is with default cache type. Maybe it is totally my design issue, if I use Castor, I'd better not touch db externally. thank you. Regards ------------ Zhongling "Alex" Li -----Original Message----- From: Thomas Yip [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 16, 2001 2:02 PM To: [EMAIL PROTECTED] Subject: Re: [castor-dev] Concurrent transaction problem. Help ! -----Original Message----- >From: Li, Alex [mailto:[EMAIL PROTECTED]] >Sent: Tuesday, October 16, 2001 1:30 PM >To: [EMAIL PROTECTED] >Subject: Re: [castor-dev] Concurrent transaction problem. Help ! > >We got the same problems here, WebLogic 6.1 + Oracle 8.1.7 + CVS Castor jar >( 10/12/2001 ) > >With Castor-0.9.3.jar ( official release ), there are even more problems, I >have to mention that because I hope you guys can figure out what changes >made it better while still not stable. > >Initial problem is: Castor could not use the Connection Pool which is using >WebLogic OCI driver, even I set the jdo-config database type to "generic". >With WebLogic OCI driver, lots of weired things will happen, executing the >same OQL first time return the correct resultset, then it keeps on returning >only one record. After we switched to Oracle OCI driver, seems Castor works >fine at first. We never tried WebLogic OCI. However, we did succeed with Castor with Tyrex, after workarounds and bug fixes. In our experience, not that much can be done in the Castor side. In fact, the Castor connection mechanism is pretty simple. Get a connection when the getDatabase is created, use the connection and close it and commit or rollback it at the end. >Then we found randomly ( 1 in 3-4 times ), Castor throws >"org.exolab.castor.jdo.ObjectModifiedException: Transaction aborted: Object >of type ABC with identity 132 has been modified by a concurrent transaction >", no matter it is Connection Pool or not. I am pretty sure there is no >other transaction going on, especially in stand-alone test. > >Then I updated my Castor with CVS version. All stand-alone tests passed, >even loop several hundred times. While, the Connection Pool still is bad. I >tried to set cache-type to all kinds, does not work out, finally I keep it >default. Problem happens randomly, but if I touch the db externally, 100% it >will happen. > >Is that true that every OQL will hit the database ? Seems not in Connection >Pool env, after I changed some records, OQL gives me back very strange >resultset, part of the them are correct, part are not. Like the count is >correct, while the field values of each object seems wrong. Then, if I try >to update one of them ( no matter long tx or short tx ), definitely it gives >back ObjectModifiedException. Yes. It does. If you are using hasMoreElements(), nextElement() pair to iterate the QueryResults, then try hasMore() and next() pair, because those give you errors message. >I heard Oracle OCI driver is not thread safe, that is the reason why >WebLogic comes out with its OCI driver, even shipped inside weblogic.jar. >Sadly, Castor does not work with it. Is this the problem? > >Please help, we are going to production this week. If I still can not fix >it, I have to throw away Connection Pool. Thomas ----------------------------------------------------------- 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
