-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

View unanswered posts | View active topics


Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]


Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 2
  [ 16 posts ]  Go to page 1, 2  Next
  Previous topic | Next topic 
Author Message
awe_cz
 Post subject: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 08, 2013 12:35 pm 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
Hi,
we recently updated Hibernate from 3.x to latest 4.2.0 and started to experience problem in code deleting entities with @Version column.

Entity class (annotations for id generation are omitted):
Code:
@Entity
public class TestLock {
    @Column(name = "testLockId") @Id
    protected Long testLockId;
    @Version
    protected long version;
}


Problematic transaction (getting EntityManager, transaction begin() and commit() are omitted):

Code:
TestLock testLock = manager.getReference(TestLock.class, testLockId);
manager.lock(testLock, LockModeType.WRITE);
manager.remove(testLock);


Stacktrace:
Code:
javax.persistence.OptimisticLockException
   at org.hibernate.ejb.AbstractEntityManagerImpl.wrapStaleStateException(AbstractEntityManagerImpl.java:1413)
   at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1329)
   at org.hibernate.ejb.AbstractEntityManagerImpl.convert(AbstractEntityManagerImpl.java:1310)
   at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:80)
   at testlockcase.TestLockCase.main(TestLockCase.java:34)
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [testlockcase.entity.TestLock#10100]
   at org.hibernate.persister.entity.AbstractEntityPersister.forceVersionIncrement(AbstractEntityPersister.java:1835)
   at org.hibernate.action.internal.EntityIncrementVersionProcess.doBeforeTransactionCompletion(EntityIncrementVersionProcess.java:53)
   at org.hibernate.engine.spi.ActionQueue$BeforeTransactionCompletionProcessQueue.beforeTransactionCompletion(ActionQueue.java:662)
   at org.hibernate.engine.spi.ActionQueue.beforeTransactionCompletion(ActionQueue.java:307)
   at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:612)
   at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.beforeTransactionCommit(JdbcTransaction.java:105)
   at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.commit(AbstractTransactionImpl.java:175)
   at org.hibernate.ejb.TransactionImpl.commit(TransactionImpl.java:75)
   ... 1 more


While this example might look like a nonsense, in the real world there are things to be done between lock() and remove() and it makes sense to lock the entity.

Any ideas what might be wrong?

It looks like a bug to me, detailed logs suggest that Hibernate throws OptimisticLockException after executing query like this:

update TestLock set version=#VERSION + 1 where version=#VERSION and testLockId=#ID

which returns zero results (because the row is deleted already) - this query should not be executed after remove(), right?

Edit: This behaviour is present at least from 4.0.0.Final, as a temporary solution we are forcing PESSIMISTIC locks in our EntityManagerProxy.
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Fri Apr 12, 2013 2:48 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Quote:
Hibernate throws OptimisticLockException after executing query like this:

update TestLock set version=#VERSION + 1 where version=#VERSION and testLockId=#ID

which returns zero results (because the row is deleted already)


Correct, but it may also return zero results because the record it is still there on database but has another version.

Also consider that version is checked on deletions too:

Code:
delete from TestLock where  testLockId=#ID  and version=#VERSION


To be able to delete a record, you must have the latest version in your persistent context.
This is intended and correct behaviour, assume following scenario:

1. Transaction:
User adds comment: please delete me (Version := 2)

2. Transaction: reads that user (Version == 2)

3. Transaction (concurrent to 2. Transaction):
User again revises the comment: please don't delete me!! (Version :=3)
Commit.

Now it would not be correct anymore transaction 2 being able to delete the user,
because it takes decisions based on a obsolete informations, version == 2
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Fri Apr 12, 2013 3:14 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
I understand how this works but - there is only one transaction present and yet it fails. And only with OPTIMISTIC (default) lock. It still looks like a bug to me.
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Fri Apr 12, 2013 3:52 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Can you please log all the jdbc-activities with p6spy (= free jdbc-logger)?
So we can exaclty see which sql's are executed and if the sql's belong effectively all to the same transaction or not.
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Fri Apr 12, 2013 8:52 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
I have following code:

Code:
        manager.getTransaction().begin();
        try {
            TestLock testLock = new TestLock();
            manager.persist(testLock);
            testLockId = testLock.getTestLockId();
            manager.getTransaction().commit();
        } catch (Exception e) {
            printThrowable(e);
            manager.getTransaction().rollback();
        }
       
        manager.getTransaction().begin();
        try {
            TestLock testLock = manager.getReference(TestLock.class, testLockId);
            manager.lock(testLock, LockModeType.WRITE);
            manager.remove(testLock);
            manager.getTransaction().commit();
        } catch (Exception e) {
            printThrowable(e);
            manager.getTransaction().rollback();
        }


it executed following commands in the database:

Code:
2013-04-12 14:49:58 CEST LOG:  duration: 0.050 ms  parse S_1: BEGIN
2013-04-12 14:49:58 CEST LOG:  duration: 0.011 ms  bind S_1: BEGIN
2013-04-12 14:49:58 CEST LOG:  duration: 0.010 ms  execute S_1: BEGIN
2013-04-12 14:49:58 CEST LOG:  duration: 0.897 ms  parse <unnamed>: select allocated from PKGen where genId = 'PKGen' for update
2013-04-12 14:49:58 CEST LOG:  duration: 0.033 ms  bind <unnamed>: select allocated from PKGen where genId = 'PKGen' for update
2013-04-12 14:49:58 CEST LOG:  duration: 0.049 ms  execute <unnamed>: select allocated from PKGen where genId = 'PKGen' for update
2013-04-12 14:49:58 CEST LOG:  duration: 0.385 ms  parse <unnamed>: update PKGen set allocated = $1 where allocated = $2 and genId = 'PKGen'
2013-04-12 14:49:58 CEST LOG:  duration: 0.107 ms  bind <unnamed>: update PKGen set allocated = $1 where allocated = $2 and genId = 'PKGen'
2013-04-12 14:49:58 CEST DETAIL:  parameters: $1 = '128', $2 = '127'
2013-04-12 14:49:58 CEST LOG:  duration: 0.052 ms  execute <unnamed>: update PKGen set allocated = $1 where allocated = $2 and genId = 'PKGen'
2013-04-12 14:49:58 CEST DETAIL:  parameters: $1 = '128', $2 = '127'
2013-04-12 14:49:59 CEST LOG:  duration: 0.030 ms  parse S_2: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 0.009 ms  bind S_2: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 23.675 ms  execute S_2: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 0.052 ms  parse S_3: BEGIN
2013-04-12 14:49:59 CEST LOG:  duration: 0.006 ms  bind S_3: BEGIN
2013-04-12 14:49:59 CEST LOG:  duration: 0.010 ms  execute S_3: BEGIN
2013-04-12 14:49:59 CEST LOG:  duration: 0.186 ms  parse <unnamed>: insert into TestLock (updated, version, testLockId) values ($1, $2, $3)
2013-04-12 14:49:59 CEST LOG:  duration: 0.052 ms  bind <unnamed>: insert into TestLock (updated, version, testLockId) values ($1, $2, $3)
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '0', $2 = '0', $3 = '12700'
2013-04-12 14:49:59 CEST LOG:  duration: 0.082 ms  execute <unnamed>: insert into TestLock (updated, version, testLockId) values ($1, $2, $3)
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '0', $2 = '0', $3 = '12700'
2013-04-12 14:49:59 CEST LOG:  duration: 0.055 ms  parse S_4: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 0.014 ms  bind S_4: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 1.134 ms  execute S_4: COMMIT
2013-04-12 14:49:59 CEST LOG:  duration: 0.026 ms  bind S_3: BEGIN
2013-04-12 14:49:59 CEST LOG:  duration: 0.005 ms  execute S_3: BEGIN
2013-04-12 14:49:59 CEST LOG:  duration: 0.363 ms  parse <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-12 14:49:59 CEST LOG:  duration: 0.157 ms  bind <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '12700', $2 = '0'
2013-04-12 14:49:59 CEST LOG:  duration: 0.070 ms  execute <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '12700', $2 = '0'
2013-04-12 14:49:59 CEST LOG:  duration: 0.104 ms  parse <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-12 14:49:59 CEST LOG:  duration: 0.083 ms  bind <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '1', $2 = '12700', $3 = '0'
2013-04-12 14:49:59 CEST LOG:  duration: 0.039 ms  execute <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-12 14:49:59 CEST DETAIL:  parameters: $1 = '1', $2 = '12700', $3 = '0'
2013-04-12 14:49:59 CEST LOG:  duration: 0.034 ms  parse S_5: ROLLBACK
2013-04-12 14:49:59 CEST LOG:  duration: 0.010 ms  bind S_5: ROLLBACK
2013-04-12 14:49:59 CEST LOG:  duration: 0.029 ms  execute S_5: ROLLBACK
2013-04-12 14:49:59 CEST LOG:  unexpected EOF on client connection
2013-04-12 14:49:59 CEST LOG:  unexpected EOF on client connection


SSCCE can be found in Hibernate JIRA under HHH-8161.
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 15, 2013 3:27 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Debugging the testcase I saw that LockModeType.WRITE is mapped to LockMode.OPTIMISTIC_FORCE_INCREMENT
which in Hiberante4 is being not executed immediately, but delayed to commit-time which is correct behavior.
I don't know how it was in Hiberante3, but it does not really matter since
you say, you need the lock being already active between lock() and remove().
This means that what you actually want is a PESSIMISTIC lock.
Under that point of view, forcing pessimistic lock (PESSIMISTIC_FORCE_INCREMENT) is'nt just a temporary solution, it's the solution par excellence.
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 15, 2013 4:23 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
pb00067 wrote:
Debugging the testcase I saw that LockModeType.WRITE is mapped to LockMode.OPTIMISTIC_FORCE_INCREMENT
which in Hiberante4 is being not executed immediately, but delayed to commit-time which is correct behavior.
I don't know how it was in Hiberante3, but it does not really matter since
you say, you need the lock being already active between lock() and remove().
This means that what you actually want is a PESSIMISTIC lock.
Under that point of view, forcing pessimistic lock (PESSIMISTIC_FORCE_INCREMENT) is'nt just a temporary solution, it's the solution par excellence.


Yes, OPTIMISTIC locks are default in Hibernate4, and always were (even in Hibernate3). One would have expected the delete to be delayed to commit as well. Is there any documentation that would explicitly state that?

I have no problem with forcing PESSIMISTIC locks, we already have EntityManager proxy in place for logging and in fact that's exactly what I did already. What worries me is different timing of all the operations which could lead to previously unknown bugs (in our code, of course).
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 15, 2013 5:50 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Quote:
One would have expected the delete to be delayed to commit as well.


The delete is in fact delayed to commit as well.
The problem is, that hibernate on commit does first the delete and then the increment-update, so it gets the OptimisticLockException
because the number of updated records is 0 instead to 1.
Under this point of view, it is effectively a bug.
On the other hand someone could argue, that a sequence Lock OPTIMISTIC_FORCE_INCREMENT, Delete has no sense at all.
(why force a optimistic lock increment, if you are going to delete the entity anyway?)

Quote:
What worries me is different timing of all the operations which could lead to previously unknown bugs (in our code, of course).


I guess Hibernate development team is not interested in bugs affect to Hiberante3 only,
because branch Hiberante3 it is not supported anymore (at least for minor issues such this).
What might be of interest (especially for you), is to know whether with Hibernate3 your Write-Lock request did force an immediate lock increment sql-update at all or if it was defered to commit too.
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 15, 2013 10:11 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
pb00067 wrote:
Quote:
One would have expected the delete to be delayed to commit as well.


The delete is in fact delayed to commit as well.
The problem is, that hibernate on commit does first the delete and then the increment-update, so it gets the OptimisticLockException
because the number of updated records is 0 instead to 1.
Under this point of view, it is effectively a bug.
On the other hand someone could argue, that a sequence Lock OPTIMISTIC_FORCE_INCREMENT, Delete has no sense at all.
(why force a optimistic lock increment, if you are going to delete the entity anyway?)


Why? Well you might have something linked to that entity, for example?

pb00067 wrote:
Quote:
What worries me is different timing of all the operations which could lead to previously unknown bugs (in our code, of course).


I guess Hibernate development team is not interested in bugs affect to Hiberante3 only,
because branch Hiberante3 it is not supported anymore (at least for minor issues such this).
What might be of interest (especially for you), is to know whether with Hibernate3 your Write-Lock request did force an immediate lock increment sql-update at all or if it was defered to commit too.


I don't expect anyone to fix Hibernate3, it is not broken. Hibernate4 is;)
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Thu Apr 18, 2013 3:29 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Before we go further with any discussion I pray you to check concretely if with Hibernate3 your Write-Lock request:
- did force an lock increment sql-update on database immediately
or if it
- did schedule a lock increment sql-update on database which is then executed at commit
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Fri Apr 19, 2013 9:30 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
Well, the change in behaviour did not come with Hibernate4, it came with Hibernate3 - in 3.5.0. It was working properly in 3.3.1 we've been used and it is not working in anything later than 3.5.0 (inclusive).

Hibernate 3.3.1:

Quote:
2013-04-19 15:21:34 CEST LOG: duration: 0.032 ms bind S_1: BEGIN
2013-04-19 15:21:34 CEST LOG: duration: 0.005 ms execute S_1: BEGIN
2013-04-19 15:21:34 CEST LOG: duration: 0.609 ms parse <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:21:34 CEST LOG: duration: 0.204 ms bind <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:21:34 CEST DETAIL: parameters: $1 = '1', $2 = '13100', $3 = '0'
2013-04-19 15:21:34 CEST LOG: duration: 0.061 ms execute <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:21:34 CEST DETAIL: parameters: $1 = '1', $2 = '13100', $3 = '0'
2013-04-19 15:21:34 CEST LOG: duration: 0.094 ms parse <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:21:34 CEST LOG: duration: 0.076 ms bind <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:21:34 CEST DETAIL: parameters: $1 = '13100', $2 = '1'
2013-04-19 15:21:34 CEST LOG: duration: 0.053 ms execute <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:21:34 CEST DETAIL: parameters: $1 = '13100', $2 = '1'
2013-04-19 15:21:34 CEST LOG: duration: 0.020 ms bind S_2: COMMIT
2013-04-19 15:21:34 CEST LOG: duration: 5.326 ms execute S_2: COMMIT


Hibernate 3.5.0

Quote:
2013-04-19 15:27:53 CEST LOG: duration: 0.033 ms bind S_1: BEGIN
2013-04-19 15:27:53 CEST LOG: duration: 0.006 ms execute S_1: BEGIN
2013-04-19 15:27:53 CEST LOG: duration: 0.605 ms parse <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:27:53 CEST LOG: duration: 0.200 ms bind <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:27:53 CEST DETAIL: parameters: $1 = '13200', $2 = '0'
2013-04-19 15:27:53 CEST LOG: duration: 0.053 ms execute <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-19 15:27:53 CEST DETAIL: parameters: $1 = '13200', $2 = '0'
2013-04-19 15:27:53 CEST LOG: duration: 0.100 ms parse <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:27:53 CEST LOG: duration: 0.086 ms bind <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:27:53 CEST DETAIL: parameters: $1 = '1', $2 = '13200', $3 = '0'
2013-04-19 15:27:53 CEST LOG: duration: 0.041 ms execute <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-19 15:27:53 CEST DETAIL: parameters: $1 = '1', $2 = '13200', $3 = '0'
2013-04-19 15:27:53 CEST LOG: duration: 0.028 ms parse S_3: ROLLBACK
2013-04-19 15:27:53 CEST LOG: duration: 0.010 ms bind S_3: ROLLBACK
2013-04-19 15:27:53 CEST LOG: duration: 0.025 ms execute S_3: ROLLBACK
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 22, 2013 2:40 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Still waiting the answer to my question.
(the logs you reported don't contain the answer to the question I've put)
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 22, 2013 3:22 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
pb00067 wrote:
Still waiting the answer to my question.
(the logs you reported don't contain the answer to the question I've put)


I think they do. You can clearly see that 3.3.x does update set version first (before delete) while 3.5.x does that after delete.
Top
 Profile  
 
pb00067
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 22, 2013 5:15 am 
Expert
Expert

Joined: Tue Jun 16, 2009 3:36 am
Posts: 990
Please don't put the focus on the sequence of actions only.
I you read my question with attention,
you will maybe notice that I'm not interested primarily on the sequence of actions.
I'm interested to know, if the write-Lock request did force an lock increment sql-update on database immediately
or if it did schedule a lock increment sql-update on database which is then executed at commit.
I don't know how I could express is more clearly.
Please put a Thread.sleep(10000) between lock request and commit, so it will figure out from the timestamps in the logfiles.
Top
 Profile  
 
awe_cz
 Post subject: Re: OptimisticLockException after lock() and remove() calls
PostPosted: Mon Apr 22, 2013 6:43 am 
Newbie

Joined: Mon Feb 11, 2013 7:44 am
Posts: 9
pb00067 wrote:
Please don't put the focus on the sequence of actions only.
I you read my question with attention,
you will maybe notice that I'm not interested primarily on the sequence of actions.
I'm interested to know, if the write-Lock request did force an lock increment sql-update on database immediately
or if it did schedule a lock increment sql-update on database which is then executed at commit.
I don't know how I could express is more clearly.
Please put a Thread.sleep(10000) between lock request and commit, so it will figure out from the timestamps in the logfiles.


Sorry about that. It looks like 3.5.x is more "lazy" as all is done in commit(), added calls to waitAndLog() method which waits for 1s, logs and waits for another 1s.

Code:

Quote:
waitAndLog("before begin");
manager.getTransaction().begin();
try {
waitAndLog("before getref");
TestLock testLock = manager.getReference(TestLock.class, testLockId);
waitAndLog("before lock");
manager.lock(testLock, LockModeType.WRITE);
waitAndLog("before remove");
manager.remove(testLock);
waitAndLog("before commit");
manager.getTransaction().commit();
waitAndLog("after commit");
} catch (Exception e) {
printThrowable(e);
waitAndLog("before rollback");
manager.getTransaction().rollback();
waitAndLog("after rollback");
}


Hibernate 3.3.1

Quote:
2013-04-22 12:36:46.250 CEST before begin
2013-04-22 12:36:51.258 CEST LOG: duration: 0.006 ms execute S_1: BEGIN
2013-04-22 12:36:48.254 CEST before getref
2013-04-22 12:36:50.256 CEST before lock
2013-04-22 12:36:51.259 CEST LOG: duration: 0.060 ms execute <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-22 12:36:51.259 CEST DETAIL: parameters: $1 = '1', $2 = '14600', $3 = '0'
2013-04-22 12:36:52.260 CEST before remove
2013-04-22 12:36:54.262 CEST before commit
2013-04-22 12:36:55.264 CEST LOG: duration: 0.063 ms execute <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-22 12:36:55.264 CEST DETAIL: parameters: $1 = '14600', $2 = '1'
2013-04-22 12:36:55.289 CEST LOG: duration: 20.015 ms execute S_2: COMMIT
2013-04-22 12:36:56.290 CEST after commit


Hibernate 3.5.0

Quote:
2013-04-22 12:39:23.317 CEST before begin
2013-04-22 12:39:25.322 CEST before getref
2013-04-22 12:39:27.324 CEST before lock
2013-04-22 12:39:29.328 CEST before remove
2013-04-22 12:39:31.330 CEST before commit
2013-04-22 12:39:32.332 CEST LOG: duration: 0.006 ms execute S_1: BEGIN
2013-04-22 12:39:32.333 CEST LOG: duration: 0.061 ms execute <unnamed>: delete from TestLock where testLockId=$1 and version=$2
2013-04-22 12:39:32.333 CEST DETAIL: parameters: $1 = '14700', $2 = '0'
2013-04-22 12:39:32.335 CEST LOG: duration: 0.041 ms execute <unnamed>: update TestLock set version=$1 where testLockId=$2 and version=$3
2013-04-22 12:39:32.335 CEST DETAIL: parameters: $1 = '1', $2 = '14700', $3 = '0'
2013-04-22 12:39:32.337 CEST LOG: duration: 0.025 ms execute S_3: ROLLBACK
2013-04-22 12:39:33.341 CEST before rollback
Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  Page 1 of 2
  [ 16 posts ]  Go to page 1, 2  Next

Board index » Hibernate & Java Persistence » Hibernate Users

All times are UTC - 5 hours [ DST ]

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.