-
1. Re: Pojo cache performance and concurrency problem
jason.greene Apr 23, 2008 12:35 PM (in response to waldekc)If I understand you correctly, are you asking for the exact behavior of BlockingQueue? (a guarantee that only one node will ever read an entry). To do this you need a distributed lock, which we don't yet support (they usually aren't desired in a cache since it negatively impacts scalability).
A JMS queue might fit your use-case better. -
2. Re: Pojo cache performance and concurrency problem
waldekc Apr 23, 2008 1:09 PM (in response to waldekc)Thanks
Bad news
Yes, JMS queue was my first choice, but it has one big limitation for me - you cannot freely modify queue (random access to messages, changing priority ..).
Because of that I checked JbossCache
And maybe you know any alternatives ? -
3. Re: Pojo cache performance and concurrency problem
jason.greene Apr 23, 2008 2:43 PM (in response to waldekc)You could do this with any kind of shared data source that supports global lock acquisition. You could use an RDBMS that supports "select for update" for example. You could also build a simple communication layer over your own data structure (that locks appropriately), or something like BDB, if you want persistence. It's fairly easy to do this with jgroups. You might be able to extend the jgroups DistributedQueue example to do what you want, although it was designed around the idea of a lot of local non-mutating reads, which i am guessing doesn't match your case.
We do have selective distributed locking on the roadmap (for specialized cases like this), but there are some higher priority features like partitioning and mvcc that we are focusing on atm. Sorry I am not much help here.