-
1. Re: Getting lots of timeoutexception
"anandlramadurg" wrote:
I am getting lot of timeoutexception. Its trying obtain the readlock on the nodes when i use pojoCache.find() API. Is there any way to avoid this.???
I mean, i dont want pojocache to obtain a readlock on a node. It should just return the object attached to that node.
Why do we need read locks?????
The underlying data can be modified by concurrent activity, including remote nodes on the cluster. In order to provide transactional isolation guarantees (you don't see non-committed changes), there has to be some form of synchronization. Pessimistic locking, which you are using, is the most simplistic locking mode in the core cache. It is intended for applications that do not have a heavy mixing of reads and writes on the same node. Decreasing your transaction span can help minimize timeouts.
Optimistic locking allows readers to not be blocked by writers, in exchange for extra memory allocation and copying. A big difference with this model though, is that concurrent writers are detected at tx commit and rolled back at that time (instead of waiting in line). This is probably what you are looking for.
Also, I should mention that in 3.0 we will be introducing a new locking model, MVCC, which will be superior to both pessimistic and optimistic models. -
2. Re: Getting lots of timeoutexception
I am using pojocache where frequency of data writes are very very less , and data reads are very very high.
We are using following configuration
isolation level - Read Commited
cache mode - REPL_SYNC ( we have clusterred environment )
Is it the most preffered configuration for my above requirements. ??
--------------------------------------------------------------------------------------
I have a helper class which puts objects in cache, something like this.
pojoCache.attach(fqn, obj)
This class is being accessed from a trasaction ( session bean ), pojoCache.attach(fqn, obj) obtains a lock on the node and it will not release the write lock until parent trasaction ( session bean method) commits.
Is there any way to make pojoCache.attach(fqn, obj) to starts its own trasaction??? I dont want this to be part of parent transaction. -
3. Re: Getting lots of timeoutexception
"anandlramadurg" wrote:
I am using pojocache where frequency of data writes are very very less , and data reads are very very high.
We are using following configuration
isolation level - Read Commited
cache mode - REPL_SYNC ( we have clusterred environment )
Is it the most preffered configuration for my above requirements. ??
Yeah, that looks fine.
I have a helper class which puts objects in cache, something like this.
pojoCache.attach(fqn, obj)
This class is being accessed from a trasaction ( session bean ), pojoCache.attach(fqn, obj) obtains a lock on the node and it will not release the write lock until parent trasaction ( session bean method) commits.
Is there any way to make pojoCache.attach(fqn, obj) to starts its own trasaction??? I dont want this to be part of parent transaction.
Sure, as long as you are ok with having state in the cache that might have been rolled back from some other data source by the beans transaction.
The easiest way to do this, since you are using CMT, is to just create another bean method that has requiresNew as the transactional attribute. Then you just call your helper class from that.
Otherwise there is a more involved approach where you can actually get at the underlying transaction API using the cache, and suspend the current transaction. If you do this, you have to make sure you restore it in a finally block, else you can leak transactions (very bad).
The code would look something like thisTransactionManager tm = pojoCache.getCache().getConfiguration().getRuntimeConfig() .getTransactionManager(); Transaction current = tm.suspend(); try { tm.begin(); pojoCache.attach(..); // Other interesting things tm.commit(); } finally { tm.resume(current); }
If you still see locking issues, give optimistic locking a try. -
4. Re: Getting lots of timeoutexception
Really appreciate your quick respsonses :)
Will try with optimistic locking and check the behaviour.
I am facing another problem in pojocache. Its explained in another thread
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=133293