[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
gsheldon(a)redhat.com made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Technical note added. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
New Contents:
Cause:When the JDBC Cache Store is configured without specifying connnectionFactoryClass,
the ManagedConnectionFactory is selected by default.
Consequence: ManagedConnectionFactory is unable to connect to the database.
Fix: None
Result: Specify connnectionFactoryClass in jdbc cache store prior to attempting a
transaction. Failure to do so will result in a connection error via the
ManagedConnectionFactory.
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL:
https://issues.jboss.org/browse/ISPN-586
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores, Transactions
Affects Versions: 4.1.0.CR2
Reporter: Manik Surtani
Assignee: Mircea Markus
Labels: cachestore, jdbc, transactions
Fix For: 4.1.0.CR3
From the reporter:
"Anyways, what seems to be the real problem is that all the things that need to be
persisted are saved in memory and then when the transaction is completing (either in
prepare or commit phase) the loader attempts to get a connection from the datasource.
Apparently this is illegal and throws an exception which is what causes the
HeuristicMixedException further up the chain.
This only fails when using a ManagedConnectionFactory. If I swap out a
PooledConnectionFactory it works fine. I presume the managed version fails because it
returns the same connection that is part of the active transaction for that thread and you
can't perform new operations on that connection once the transaction is already in
prepare or commit. This feels like a bit of a design flaw to me... I didn't see an
obvious fix."
This possibly has to do with the AbstractCacheStore doing the following in prepare():
"
public void prepare(List<? extends Modification> mods, GlobalTransaction tx,
boolean isOnePhase) throws CacheLoaderException {
if (isOnePhase) {
applyModifications(mods);
} else {
transactions.put(tx, mods);
}
}
"
and later during commit actually writing the changes to the store. This generic,
"abstract" behaviour is intended for non-transactional data stores (such as a
filesystem). Behaviour should be different when it comes to transactional data stores.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira