Niklas Eklund wrote:
Oliver Zeigermann wrote:
Niklas Eklund wrote:
Hi Oliver,
Yes, but there are two stores involved that have different connections, right? Or does the structure and content store now share the same connection during the transaction? (I rewrote stores for slide1 to do
Only one store...
Ok, I see. And it is the same connection all the way?
that, but I am not familiar with the new db-stores as I have only used the filestore in slide2)
If it is two connections, maybe the same table is written to by both connections? Maybe to update last modified, history, or something?
No no, it works for all other db ports, only Oracle is causing problems.
Yes, but Oracle is picky.. :) MySql for instance will let you get away with just about anything...
Not the 4.x version with serializable transactions (uses pessimistic locking). Same thing with Sybase and MSSQL server. Actually, Postgres should almost have the same isolation strategy as Oracle, but works fine...
Could there be a problem with delete ... where id in (select ... from ...)? Just wondering...
Any idea if there is a tool that allows me to inspect all current locks and transactions in Oracle to see what might be going on? EM delivered with Oracle 10g really isn't that helpful :(
I'm not that familiar with administration stuff for Oracle, but I have seen that you can inspect sessions in the EM somewhere (v9 at least), and see held locks and what sql is being performed.
Otherwise there is always P6Spy (http://www.p6spy.com/).
Thanks, I will try it :)
Cheers,
Oliver
Regards, Niklas
Thanks and cheers,
Oliver
Regards, Niklas
Oliver Zeigermann wrote:
Hi Niklas!
Thanks for your help. However, the problem occurs also when a *single* request is performed. I also checked for unclosed resources, but found none. I will try findbugs...
Cheers,
Oliver
Niklas Eklund wrote:
Oliver Zeigermann wrote:
... when Isolation level is set to serializable, works fine when set to read committed!
Serializable transactions fail if a row in transaction a has been modified by another transaction b after a has started.
(source: http://www.csee.umbc.edu/help/oracle8/java.815/a64684/alangfe5.htm)
This might be difficult or practically impossible to "fix" without some sort of external lock when using multiple connections as I guess is the case here...
Problem is transactions that do deletes fail occasionally. All this seems like there still are reading transactions not yet committed or rolled back. Anyone any idea whether the transaction gets closed in Oracle when you close the connection the transaction was started on?
I don't know when (if) a transaction gets aborted/committed implicitely, but if the connection is pooled (perhaps by the driver itself) the connection is not really closed on the call to close() but just recycled as you probably know. Then the next user of the same connection will enter in the middle of an unfinished transction. The _only_ solution to these kinds of problems is to make sure that there are try/catch-clauses surrounding all operations making sure everything is in a consistent state no matter what happens.
I can recommend FindBugs (http://findbugs.sourceforge.net/) to find such (and other) problems.
Regards,
Niklas
Hmmmm,
Oliver
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
