This week's book giveaway is in the XML and Related Technologies forum.
We're giving away four copies of Java XML & JSON and have Jeff Friesen on-line!
See this thread for details.
Win a copy of Java XML & JSON this week in the XML and Related Technologies 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 ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Devaka Cooray
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Paul Clapham
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • salvin francis
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Frits Walraven
  • Ganesh Patekar

enabling transactional row/key level locking in ehcache  RSS feed

 
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We are trying to avoid processing similar requests that arrive at same time and return the result of the first successfully processed request. We do this by simply ignoring duplicates by making an entry in cache that there was already a request with a similar known key. But this fails if threads arrive at the same time and all of them successfully do a put even before gets start working or if the first request fails.

In an example of two threads thread1, thread2 arriving at the same time thread1 leading thread2 in put:
1. If two threads arrive at the same time and attempt to make an entry in ehcache at the same time, how can we force ehcache to allow only one entry and fail the next ones by using putIfAbsent or any other means. How do we enable a row level locking with dirty read? Is there a corresponding annotation to do this explicit write/read locking as well or does putIfAbsent does this by default http://ehcache.org/documentation/2.8/apis/explicitlocking? I know the default replace/putIfAbsent behavior is atomic, but still want to confirm if this is true, otherwise why do we need read/write locks?
2. Is it possible for the remaining threads to "wait on a put like acquiring a lock" or say we open a transaction on the first thread that is processing the request and will not put a value until it succeeds?

All of this in a distributed ehcache context.
 
Ranch Hand
Posts: 662
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

rad kri


- Please read the Naming Policy of java ranch here.
If you think it's inappropriate you can change the name here.
 
rad kri
Greenhorn
Posts: 10
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My name means no offense to anyone and there is nothing wrong in staying anonymous or having such a name .
 
All of the world's problems can be solved in a garden - Geoff Lawton. Tiny ad:
RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
https://coderanch.com/t/704633/RavenDB-Open-Source-NoSQL-Database
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!