[
https://jira.jboss.org/jira/browse/JBCACHE-991?page=com.atlassian.jira.pl...
]
Michael Youngstrom commented on JBCACHE-991:
--------------------------------------------
I don't have an answer to all your questions. My main goal in voting for this issue
was the hope of to eliminating my dependence upon JTA.
I've run into several problems with how different TransactionMangers synchronize has
frequently caused problems for me. I'm hoping this will give me more options to deal
with such problems when they arise.
I'd also like to have the option of using JBC in a lighter resource local scenario.
I'd also like to be able to adapt my use of JBC batching to other synchronization
models (Servlet Filter, Spring TX Synchronization, etc.)
I know Websphere ObjectGrid uses a programmatic approach to transaction management by
creating a simple Tx api similar to JPA's EntityTransaction model.
(
http://www-128.ibm.com/developerworks/wikis/display/objectgridprog/Progra...)
that allow for all of the above.
Anyway, my main hope is to have a fairly simple API that I can use to manage the
cache's transactions or batches without requiring JTA.
Mike
Non-JTA based mechanism for batching invocations
------------------------------------------------
Key: JBCACHE-991
URL:
https://jira.jboss.org/jira/browse/JBCACHE-991
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Reporter: Brian Stansberry
Assignee: Mircea Markus
Fix For: 3.0.0.GA
Currently JBC uses the lifecycle of a JTA Transaction to scope a series of cache
invocations doing things like lock release, replication and cache loader storage as part
of the transaction commit. Need a mechanism to do this kind of invocation batching that
doesn't depend on JTA. Needed to allow callers that don't wish their work to be
associated with an active JTA transaction to still get the batching behavior JBC
provides.
AS web session replication is an example use case. It uses BatchModeTransactionManger to
ensure its activity doesn't impact any ongoing transaction. But
BatchModeTransactionManager isn't a good JTA transaction manager even though it
implements the JTA interfaces. So using it is problematic; it can easily be misused by
those who don't understand it's limitations (e.g. hooking it up to a JTA
Datasource.)
A couple of possible approaches have been discussed:
1) A new API added to Cache. Methods like startBatch(), commitBatch(), rollbackBatch(),
along with some internal mechanism to timeout a batch that's been started but never
committed/rolled-back.
2) Abstract away the JTA API such that JBC doesn't use JTA directly, but rather its
own interfaces that largely parallel TransactionManager and Transaction. Provide an impl
that simply wraps a real JTA TransactionManager. BatchModeTransactionManger would be
another impl. API includes a method like 'boolean isJTACompliant()' that things
like CacheLoader impls can check at startup to confirm they are working with a compatible
impl (e.g. if JBDCCacheLoader is configured to use a JTA Datasource but isJTACompliant()
returns false, throw an exception at startup.)
Apologies if this is a duplicate issue. Thought there was something like this but
couldn't find it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira