[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
[JBoss JIRA] Created: (ISPN-1103) Soft schema-based storage
by Manik Surtani (JIRA)
Soft schema-based storage
-------------------------
Key: ISPN-1103
URL: https://issues.jboss.org/browse/ISPN-1103
Project: Infinispan
Issue Type: Feature Request
Components: Core API
Reporter: Manik Surtani
Assignee: Manik Surtani
Fix For: 5.1.0.BETA1, 5.1.0.Final
This JIRA is about storing metadata alongside values. Perhaps encapsulating values as SchematicValues, which could be described as:
{code}
class SchematicValue {
String jsonMetadata;
String jsonObject;
}
{code}
Metadata would allow for a few interesting features:
* Extracting of lifespan and timestamp data if manipulated over a remote protocol (REST, HotRod, etc)
* Content type for REST responses
* Timestamps for REST headers, will affect HTTP content caches
* Validation information (may not be processed by Infinispan, but can be used by client libs)
* Classloader/marshaller/classdef version info
* General structure of the information stored
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months
[JBoss JIRA] Created: (ISPN-939) Index corruption when remote node dies during commit
by Tristan Tarrant (JIRA)
Index corruption when remote node dies during commit
----------------------------------------------------
Key: ISPN-939
URL: https://issues.jboss.org/browse/ISPN-939
Project: Infinispan
Issue Type: Bug
Components: Lucene Directory
Affects Versions: 4.2.1.CR2
Reporter: Tristan Tarrant
Assignee: Sanne Grinovero
Using a scenario similar to the one described in ISPN-909:
Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction, hash numOwners=2)
Node 1: coordinator, IndexWriter open constantly and writing a stream of documents, committing after each one
Node 2: opens a read-only IndexReader to perform queries, using reopen to keep in sync with the updates coming from node 1
If we "kill -9" node 2 (to simulate a crash), we get a SuspectException in node 1 during the pre-commit phase (within IndexWriter.commit()). Catching the Throwable we then close() the writer but from then on we get "Read past EOF" errors when trying to access the index (both with readers and writers).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 2 months