Did you try Requires new or the JTA suggestion I gave in your other locking thread? These both involve creating a separate transaction that does not affect your current one.
If you really don't want POJO Cache to use your transaction manager, then set TransactionManagerLookup to
Approach1: creating new trasaction using session bean method involves overhead. So cant go with that approach
Appraoch2: using JTA Api's to resume the parent transaction and performing caching operation also involves overhead and its more ciritcal.. [:(]. So cant go with this approach also.
And moreover my caching operations are not related to any trasactions, even if the trasaction fails and my caching opertions are successfull, i dont mind.
I have just removed
from configuration file. And my caching operations are running without any trasactions.
Is this sufficient or I should add
as suggested by you???
I have removed attribute 'TransactionManagerLookupClass' from the caching configuration file.
Is this sufficient?? or I should add this element with value 'TransactionManagerLookup' ???
The overhead of creating a transaction via a tm (at least using ours) is small. POJO Cache always uses transactions, since a single field update or attach involved multiple core cache operations. You can either let the container tm manage it, or use the dummy tm, which is an overly simple tm designed for batching/testing. If you remove the attribute the default applies, which is to detect the current comtainer TM, so removing it will not change anything in this case.
But it is working in my case. I have removed the attribute ''TransactionManagerLookupClass' ' from configuration file.
Caching operations are not being part of the parent trasaction !!!.
I am using WLS10 with container managed trasaction.
I get the same behaviour when i add DummyTransactionManagerLookup for TransactionManagerLookupClass attribute.
So, Removing the attribute and adding DummyTransactionManagerLookup as trasactionmanager, both are behaving same.
Ah, I had assumed you were on JBoss AS, not WLS.
The default of this option is JBossTransactionManagerLookup, which only looks for the JBoss TM. You must have had it set to GenericTransactionManagerLookup before. If the TM lookup fails, POJO Cache will use the Dummy TM, so thats why you get the same behavior.