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 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?
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]
