-->
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.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Transactional Second Level Cache and Generated Identifier
PostPosted: Sat Jun 02, 2012 2:24 pm 
Newbie

Joined: Sat Dec 18, 2010 7:13 pm
Posts: 4
I have the following stack:

Hibernate 3.6.9.Final
Spring 3.1.1
Atomikos 3.7.1
Infinispan 4.2.1.FINAL
MySQL

I have been writing a few tests to ensure that when a RuntimeException is thrown the current transaction is rolled back on the database but also on the transactional 2LC.

I have found found some odd results which I was hoping someone could explain.

If I use an @Entity annotated with @Cache(usage=CacheConcurrencyStrategy.TRANSACTIONAL) with a String @Id which I assign in my test then I see everything I expect:

* When no exception is thrown the transaction is committed and the 2LC contains the entity, I confirmed this using:
Code:
sessionFactory.getCache().containsEntity(MyEntity.class, myIdentifier)

* If an exception is thrown neither the database or 2LC contain the entity.

However, if I repeat these tests using an @Entity which has a generated @Id (MySQL auto-incrementing long property) as shown:

Code:
@Id
@GeneratedValue
private long id;


I find that the entity is never put in the 2LC, regardless of any exceptions thrown.

I have done some debugging and it seems to be down to the different code paths in AbstractSaveEventListener#performSaveOrReplicate. For an assigned @Id useIdentityColumn is false and so we instantiate and execute a EntityInsertAction which then puts the new entity in the 2LC.

Conversely, if the @Id is generated by MySQL we find that the useIdentityColumn is true and we instantiate and execute an EntityIdentityInsertAction. This contains commented out code regarding the 2LC as shown:

Code:
//TODO: this bit actually has to be called after all cascades!
      //      but since identity insert is called *synchronously*,
      //      instead of asynchronously as other actions, it isn't
      /*if ( persister.hasCache() && !persister.isCacheInvalidationRequired() ) {
         cacheEntry = new CacheEntry(object, persister, session);
         persister.getCache().insert(generatedId, cacheEntry);
      }*/



Is there any reason for this? Should the cache insert be done elsewhere? Is this a bug?

If anyone can shed any light on this difference and how this should work I would be very grateful.


Top
 Profile  
 
 Post subject: Re: Transactional Second Level Cache and Generated Identifier
PostPosted: Thu Jun 07, 2012 11:32 am 
Newbie

Joined: Sat Dec 18, 2010 7:13 pm
Posts: 4
Does no one have any insight into why this might be happening and whether this TODO is a problem?


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

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.