Win a copy of Spring in Action (5th edition) this week in the Spring forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

JPA Persistence issue  RSS feed

Posts: 8
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

This post is regarding a persistence issue with JPA. The JPA provider used is Oracle Toplink provided by weblogic 12c and is built using EclipseLink.

The user makes 'n' number of interactions/trasnactions and the app writes each transaction to the DB.
Under heavy load, while writing the transactions, the app is facing duplicate key exceptions.
The 1st transaction is written successfully to the DB but the subsequent transaction is sometimes rejected with the duplicate key exception.

As i said the app uses JPA 2.0 in which the shared cache is enabled by default and i think this is something to do with shared cache.
I say this because the same app works fine in Weblogic 10 which uses JPA 1.0 and there is no concept of shared cache in there.

Now back to the issue, Each entity that takes part in the insert transaction is uniquely identitified by an embedded primary key class with overridden
hashcode/equals() (Please see below for the class definition).

The primary key is the combination of sessionid(FIRST_USER_SESSION) and the transaction number (01 for first insert, 02 for second insert ....)
For e.g: FIRST_USER_SESSION and 01

1st transaction pk: FIRST_USER_SESSION01
2nd transaction pk: FIRST_USER_SESSION02

1. Before writing the 1st insert transaction(entity with pk FIRST_USER_SESSION 01), its checked in the L2 cache and since its not in cache , its
successfully persisted to DB.

2. After writing the first transaction , its updated in the L2 cache.(entity with FIRST_USER_SESSION 01 key is cached)

3. Now for the second insert transaction(the entity with key FIRST_USER_SESSION 02), the L2 cache is checked before persisting and and its my guess that
entity for second transaction is considered identical to the one already in L2 cache. Even though the pk is different (FIRST_USER_SESSION02), i think the
framework identifies it as the duplicate object.(based on the equals() and hashcode() overridden) . As a result the same duplicate object is attempted for insert and dulicate key exception is thrown.

Question 1) Is my understanding correct
Question 2) If this is the case, can i make the entity to use isolated cache and refresh always and expire instantly(like highlighted below).
I just want the cache to be disabled for this entity, Please let me know your comments

Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!