[JBoss JIRA] Created: (ISPN-317) when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
by Mircea Markus (JIRA)
when unsafeReturnValues is false, combine put, remove, replace, putIfAbsent, to pull back responses in 1 command
----------------------------------------------------------------------------------------------------------------
Key: ISPN-317
URL: https://jira.jboss.org/jira/browse/ISPN-317
Project: Infinispan
Issue Type: Feature Request
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.1.0.CR1
at the moment this is split in two operations: a remote get followed by an put. Optimize this to only reside in one operation.
--
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
12 years, 2 months
[JBoss JIRA] Created: (ISPN-201) make JDBC cache store use DB transactions for commit/rollback
by Mircea Markus (JIRA)
make JDBC cache store use DB transactions for commit/rollback
-------------------------------------------------------------
Key: ISPN-201
URL: https://jira.jboss.org/jira/browse/ISPN-201
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores
Reporter: Mircea Markus
Assignee: Manik Surtani
Fix For: 4.0.0.GA
current impl of JDBC cache store does not use DB transaction (nor local transactions/Connection.setAutocommit(false)) for storing the modifications created within a transaction. This might leave the store in an inconsistent state one operation fails during commit. This should be changed to either 1. use local transactions or 2. register the driver as an XAResource and rely on the TM to manage the boundaries. I would go for 1, as it would be more consistent with other CStore implementation (different cache store interceptor should be used for managing the 2'nd approach).
--
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
12 years, 2 months
[JBoss JIRA] Created: (ISPN-445) Ensure that locks time out
by Phil vd (JIRA)
Ensure that locks time out
--------------------------
Key: ISPN-445
URL: https://jira.jboss.org/browse/ISPN-445
Project: Infinispan
Issue Type: Feature Request
Components: Locking and Concurrency
Reporter: Phil vd
Assignee: Manik Surtani
When a lock is acquired, no mechanism ensure that it is reclaimed later.
So if for whatever reason the thread owning the lock is stuck in an endless loop or waiting for some resource, the entry is locked. This kind of situation could happen in cache stores trying to contact a remote storage.
The risk is quite high that other entries may be locked as well if you use lock stripping (default : TRUE)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-604) Re-design CacheStore transactions
by Mircea Markus (JIRA)
Re-design CacheStore transactions
----------------------------------
Key: ISPN-604
URL: https://jira.jboss.org/browse/ISPN-604
Project: Infinispan
Issue Type: Feature Request
Components: Loaders and Stores, Transactions
Affects Versions: 4.1.0.CR2, 4.0.0.Final
Reporter: Mircea Markus
Assignee: Mircea Markus
Fix For: 5.0.0.Final
Current(4.1.x) transaction implementation in CacheStores is brocken in several ways:
1st problem.
- AbstractCacheStore.prepare:
public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
If this is 1PC we apply the modifications in the prepare phase - we should do it in the commit phase (as JTA does it).
2nd problem.
This currently exhibits during commit/rollback with JdbcXyzCacheStore, but it is rather a more general cache store issue.
When using a TransactionManager, during TM.commit AbstractCacheStore.commit is being called internally which tries to apply all the modifications that happened during that transaction.
Within the scope of AbstractCacheStore.commit, JdbcStore obtains a connection from a DataSource and tries to write the modifications on that connection.
Now if the DataSource is managed (e.g. by an A.S.) on the DS.getConnection call the A.S. would try to enlist the connection with the ongoing transaction by calling Transaction.enlistResource(XAResource xaRes) [1]
This method fails with an IllegalStateException, because the transaction's status is preparing (see javax.transaction.Transaction.enlistResource).
Suggested fix:
- the modifications should be registered to the transaction as they happen(vs. during prepare/commit as it happens now)
- this requires API changes in CacheStore, e.g.
void store(InternalCacheEntry entry)
should become
void store(InternalCacheEntry entry, GlobalTransaction gtx)
(gtx would be null if this is not a transactional call).
[1] This behavior is specified by the JDBC 2.0 Standard Extension API, chapter 7 - distributed transaction
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months