-
1. Re: Inst. Per Tx with Cache Invalidation?
aloubyansky Aug 5, 2004 4:00 AM (in response to ioparra)Check JBossCMP wiki for caching and locking.
You could use IPT for read-write container and standard container configuration with commit option A and cache invalidation for read-only container. -
2. Re: Inst. Per Tx with Cache Invalidation?
ioparra Aug 10, 2004 9:02 PM (in response to ioparra)Thanks Alex-
Read through the documentation(including paid docs) and have a few more clarifications:
1)AdminDevel_323.Page 302The JBoss developers are currently exploring ways to allow commit-option ‘A’ as well (which would allow the use of caching for this option).
Referring to IPT. Any updates on this progress for the 3.2 branch?
2)From CMP Wiki,Therefore, such verbal nonsense like 'container with pessimistic locking policy configured with CMP optimistic locking' might make sense in some clustered deployments.
For Entity with Cache Invalidation, when 2 transactions in seperate nodes modify the same row, to make sure you have data integrity, optimistic locking would be required. But this container is defaulted to QueuedPessimistic. For a clustered environment(not clustered entities), this nonsense makes sense... right?
Which leads me to:
3)What happens if CMP with Cache invalid is deployed without pessimistic locking(ie nolock or optim). Since there is only one instance, this would imply that all transactions would have complete reign over the entity and any one of them can read/modify the ejb, randomly commiting and rolling back.(sounds like a tragedy to me).
Thanks a bunch!
-Ivan -
3. Re: Inst. Per Tx with Cache Invalidation?
ioparra Aug 10, 2004 9:06 PM (in response to ioparra)Sorry, one more thing... For #2, how do you configure optimistic+pessimistic at the same time if only one locking policy is available per container?
-I -
4. Re: Inst. Per Tx with Cache Invalidation?
aloubyansky Aug 12, 2004 7:28 AM (in response to ioparra)1) yes, 3.2.6 will include a new container configuration
<container-configuration>
<!--
| This is like standard IPT but with global (cross-transactional) row cache behind,
| i.e. no locking in EJB layer + global persistence data cache
-->
<container-name>cmp2.x jdbc2 pm</container-name>
This container is a new implementation and does not have all the features of the current standard container. This was driven by SPECjAppServer2002 optimization work.
2) Right. Cache invalidation is irrelevant details here since one tx or another will invalidate it anyway.
3) Not clear for me. In cache invalidation you have two containers: RW and RO. RW can be based on IPT or Standard container. RO should be based on the standard container with CO A and possibly marked as read-only assuming it's not going to be modified.
4) Read the Locking page again where it says
Optimistic locking is not a locking policy in terms of locking policies described above, -
5. Re: Inst. Per Tx with Cache Invalidation?
ioparra Aug 25, 2004 9:21 PM (in response to ioparra)Thanks Alex, just a few more questions:
Sorry for taking so long, I wanted to have a look at the new container
1)I noticed that the their is no Cache Invalidation trigger for this container. Since it is commit option C, how long does this cache live? Is it invalidated by the InvalidationManager or is it lost at the end of all the tx? What kind of performance gain is suspected from this container.
From the documentation, I got the impression that there would be a global cache and when each IPT begins it would either Clone a context from the global cache(on a hit) or create a context in both the global/local cache(on a miss). I'm guessing that was not the goal for SPECjAppServer2002 opt.
2)Any suggestions on a read-mostly scenario with data integrity. In other words an entity is created, but is only update 1% of the time. When it is updated an invalidation occurs. What happens if this same 1% time occurs on 2 seperate nodes(unlikely, but possible), both are CacheInvalidation/Pessimistic and both will update the db based on the PK, the last update will win. If instead this contianer had optimistic lock, the update for the second instance would fail and the app would need to handle the error. Is this configuration possible? Based on the documentation, it seems like it should be. How? The container descriptor does not have a place for both pessimistic/optimistic to co-exist. Am I missing a configuration placement?
3,4) Thanks for clarifying.
-Ivan