RE: Under what circumstances a table/row is locked exclusively if Optimistic=true & LockManager=version?

[C N Davies <cn...@cndavies.com>]

Not sure if OpenJPA 2.0 has this issue, but 1.2.x had an issue whereby it would not release locks in case of duplicate inserts failing unique constraints, might be worth checking. 

Did you check the lock owner?

Chris

-----Original Message-----
From: Rick Curtis
Sent:  11/06/2010 01:31:48
Subject:  Re: Under what circumstances a table/row is locked exclusively if  Optimistic=true & LockManager=version?

We shouldn't be using any database locks. I'd suggest turning on SQL trace
[1] to see what we are issuing for SQL.

Thanks,
Rick

[1] <property name="openjpa.Log" value="SQL=trace"/>

On Thu, Jun 10, 2010 at 7:23 AM, egoosen <eg...@metropolitan.co.za>wrote:

>
> I'm experiencing a similar problem, and its really disappointing that no
> one
> has replied to this post!
>
> We are getting a SQL timeout exception on DB2 (version 8.x):
> DB2 SQL error: SQLCODE: -911, SQLSTATE: 40001, SQLERRMC: 68;
>
> The exception occurs when two processes are run, the first process is a
> long
> running transaction that inserts records into a specific table.
> The second process tries to read from the above table, and gets the timeout
> after a minute (which is what the timeout is set to on our database).
>
> We are using Optimistic locking with version column, so as far as I'm
> aware,
> the table should not be exclusively locked until the transaction is about
> to
> be committed!
>
> Using: OpenJPA 1.2.1
>
> Please HELP!!!
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/Under-what-circumstances-a-table-row-is-locked-exclusively-if-Optimistic-true-LockManager-version-tp581619p5162919.html
> Sent from the OpenJPA Users mailing list archive at Nabble.com.
>