[JBoss JIRA] Created: (JBCACHE-991) Non-JTA based mechanism for batching invocations
by Brian Stansberry (JIRA)
Non-JTA based mechanism for batching invocations
------------------------------------------------
Key: JBCACHE-991
URL: http://jira.jboss.com/jira/browse/JBCACHE-991
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Assigned To: Manik Surtani
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: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCACHE-941) org.jboss.cache.Caches, which allows for users to access a Cache using various collection interfaces
by Elias Ross (JIRA)
org.jboss.cache.Caches, which allows for users to access a Cache using various collection interfaces
----------------------------------------------------------------------------------------------------
Key: JBCACHE-941
URL: http://jira.jboss.com/jira/browse/JBCACHE-941
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Elias Ross
Assigned To: Manik Surtani
The java.util.Collections utility class supplies useful methods for dealing with legacy interfaces and wrapping collection classes for concurrency, type safety, read-only, etc.
In a simiilar vein, I wrote a "Caches" class that returns java.util.Map instances for a Node, which allow data to be modified through the standard Map interface.
This I expect to be extremely useful for allowing uses to integrate their existing application with JBoss Cache, and will eliminate some of the confusion of using a new API and they can use the API they know best. Users also often demand an API which is "generic" so that their code is not tied to a particular vendor.
There are basically two methods in Caches, one looks like this:
Cache cache = DefaultCacheFactory.getInstance().createCache();
Map m = Caches.asMap(cache);
m.put("foo", "bar");
The API and examples explain themselves.
"Caches" could also include other useful methods for printing or reporting.
Note that this functionality could be considered duplicated from PojoCache...)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCACHE-877) TreeCache usage should not depend on trove.jar
by Galder Zamarreno (JIRA)
TreeCache usage should not depend on trove.jar
----------------------------------------------
Key: JBCACHE-877
URL: http://jira.jboss.com/jira/browse/JBCACHE-877
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 1.4.0.SP1
Reporter: Galder Zamarreno
Assigned To: Manik Surtani
Priority: Minor
A customer is upgrading from JBC 1.1 to 1.4.0.SP1 and
even though it only uses plain TreeCache, it gets a
NoClassDefFoundError for trove classes.
2006-11-23 13:19:03,781 ERROR RpcDispatcher exception=java.lang.NoClassDefFoundError: gnu/trove/TObjectHashingStrategy
This is a TreeCacheAop/PojoCache dependency and therefore,
should be isolated and attempted to be loaded only when
PojoCache used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months
[JBoss JIRA] Created: (JBCACHE-772) State transfer not handled properly in case of reconnect
by Brian Stansberry (JIRA)
State transfer not handled properly in case of reconnect
--------------------------------------------------------
Key: JBCACHE-772
URL: http://jira.jboss.com/jira/browse/JBCACHE-772
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Clustering
Affects Versions: 1.4.0.SP1, 1.4.0, 1.3.0.SP3, 1.3.0.SP2, 1.3.0.SP1, 1.3.0, 1.2.4SP2, 1.2.4SP1, 1.2.4
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Fix For: 2.1.0
In createService(), TreeCache set Channel.AUTO_GET_STATE to true. This should only be done if the cache is configured to do an initial state transfer.
That's easy to fix. What's harder to fix is what to do when region-based marshalling is in effect. Probably, something like the following:
1) In viewAccepted, monitor for the case where a view is issue that doesn't include the current node. Set a flag and ??? (throw exceptions when attempts are made to use the cache???)
2) When another view is accepted that once again includes the current node, iterate through the various marshalling regions, inactivating and then reactivating them (reactivation will cause a partial state transfer).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 9 months