5:35 a.m.
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.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: Manik Surtani
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 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:04 p.m.
New subject: [JBoss JIRA] Assigned: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://jira.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.sys...
]
Manik Surtani reassigned ISPN-586:
----------------------------------
Assignee: Mircea Markus (was: Manik Surtani)
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.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
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:14 a.m.
New subject: [JBoss JIRA] Commented: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://jira.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.sys...
]
Mircea Markus commented on ISPN-586:
------------------------------------
"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"
I think the failure appears at enlistment time:
- when obtaining the connection from container's datasource it first checks to see if
a transaction is associated with the calling thread. In our scenario there is one
associated, so container's datasource tries to register the connection it is about to
return with it:
XAResounce xaRes = XAConnection.getXAResource()
tx.enlistResource(xaRes);
Last enlist call fails: from "enlistResource" javadoc: IllegalStateException
thrown if the transaction in the target object is in the prepared state or the transaction
is inactive.
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.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
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:02 a.m.
New subject: [JBoss JIRA] Resolved: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://jira.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.sys...
]
Mircea Markus resolved ISPN-586.
--------------------------------
Resolution: Won't Fix
This cannot be fixed without API changes. ISPN-604 was created and it covers this one as
well, to be addressed within 5.x.
The ManagedConnectionFactory was also amended to inform users, in case of failures, of
this limitation.
ManagedConnectionPool doesn't work in a transactional context
-------------------------------------------------------------
Key: ISPN-586
URL: https://jira.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
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 contact one of the administrators:
https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:27 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration updated ISPN-586:
-----------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=758178
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
4:59 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tristan Tarrant commented on ISPN-586:
--------------------------------------
Making the datasource not participate in JTA (i.e. adding jta="false" to the
datasource definition), "solves" it.
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
4:59 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tristan Tarrant edited comment on ISPN-586 at 11/30/11 5:59 AM:
----------------------------------------------------------------
Workaround: Making the datasource not participate in JTA (i.e. adding
jta="false" to the datasource definition), "solves" it.
was (Author: NadirX):
Making the datasource not participate in JTA (i.e. adding jta="false" to the
datasource definition), "solves" it.
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
5:01 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tristan Tarrant updated ISPN-586:
---------------------------------
Workaround Description: Add jta="false" to the datasource definition
Workaround: Workaround Exists
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=758178 (was:
https://bugzilla.redhat.com/show_bug.cgi?id=758178)
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
11:34 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tom Coates commented on ISPN-586:
---------------------------------
Making the datasource not participate in JTA transactions is not an acceptable work
around. How should we have Infinispan work take part in a JTA transaction and still use a
cache loader? How can we participate in an XA transaction?
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
12:02 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tristan Tarrant commented on ISPN-586:
--------------------------------------
It is a workaround for non-transactional uses (e.g. the servers). Obviously this will need
to be fixed in ISPN-604
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
12:08 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
Tom Coates commented on ISPN-586:
---------------------------------
Ah, thanks. I didn't see a link to ISPN-604 so I added one. Appreciate the response.
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
3:52 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Just FYI: I created AS7-3674 since I thought it was another problem but it turned out to
be the same issue as ISPN-604. So this bug is dependent on AS7-3674 which should be
automatically fixed once ISPN-604 is implemented and this change gets into Infinispan
subsystem of AS7.
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
10:03 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
prabhat jha <pjha(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Tristan, is this going to be fixed in ER03 i.e before limited availability release?
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
3:06 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Highly unlikely unfortunately
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
9:21 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
The technical_notes? flag indicates that this is a known issue. Please add summarized
cause (what caused the issue) and consequence (how the issue manifests) information about
this in the Technical Notes field.
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
3:46 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
This JAR is identical to the distributed JDG 6.0.0.ER5 JAR with the addition of
Mircea's hack to workaround the issue of using a transactional datasource with a
cachestore
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
8:42 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
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
8:44 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Technical note updated. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
Diffed Contents:
@@ -1,4 +1,4 @@
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.+Result: None
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
8:13 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
mark yarborough <myarboro(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Tristan indicates that ER6 will contain a work around in the code.
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
8:25 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
This issue has been cloned to 807674 to track the proper fix (based on ISPN-604). For JDG
6 this workaround solves the problem
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
6:54 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178] from NEW to ON_QA
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
3:24 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178] from ON_QA to VERIFIED
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
7:48 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
To include the workaround in the release note, please specify what need to be done as a
workaround in the technical notes box in addition to comments/changes to the CCFR
information.
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
12:37 a.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Misha, the workaround does not require any user action: it is now built-in behaviour.
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
8:13 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Technical note updated. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
Diffed Contents:
@@ -1,4 +1 @@
-Cause:When the JDBC Cache Store is configured without specifying connnectionFactoryClass,
the ManagedConnectionFactory is selected by default.
+Previously, when the JDBC Cache Store was configured without specifying
connnectionFactoryClass, the ManagedConnectionFactory was selected by default. As a
result, ManagedConnectionFactory could not connect to the database. This behavior is now
fixed and a connection to the database is established as expected when no
connectionFactoryClass is specified for the JDBC Cache Store.-Consequence:
ManagedConnectionFactory is unable to connect to the database.
-Fix: None
-Result: None
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
9:57 p.m.
New subject: [JBoss JIRA] (ISPN-586) ManagedConnectionPool doesn't work in a transactional context
[
https://issues.jboss.org/browse/ISPN-586?page=com.atlassian.jira.plugin.s...
]
RH Bugzilla Integration commented on ISPN-586:
----------------------------------------------
Misha H. Ali <mhusnain(a)redhat.com> made a comment on [bug
758178|https://bugzilla.redhat.com/show_bug.cgi?id=758178]
Technical note updated. If any revisions are required, please edit the "Technical
Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services
team.
Diffed Contents:
@@ -1 +1 @@
-Previously, when the JDBC Cache Store was configured without specifying
connnectionFactoryClass, the ManagedConnectionFactory was selected by default. As a
result, ManagedConnectionFactory could not connect to the database. This behavior is now
fixed and a connection to the database is established as expected when no
connectionFactoryClass is specified for the JDBC Cache Store.+Previously, when the JDBC
Cache Store was configured without specifying
<classname>connnectionFactoryClass</classname>, the
<classname>ManagedConnectionFactory</classname> was selected by default. As a
result, <classname>ManagedConnectionFactory</classname> could not connect to
the database. This behavior is now fixed and a connection to the database is established
as expected when no <classname>connectionFactoryClass</classname> is specified
for the JDBC Cache Store.
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
4583
days inactive
5247
days old
infinispan-issues@lists.jboss.org
25 comments
8 participants
participants (8)
-
Manik Surtani (JIRA) -
Mircea Markus (JIRA)
-
RH Bugzilla Integration (JIRA)
-
RH Bugzilla Integration (Updated) (JIRA)
-
Tom Coates (Commented) (JIRA)
-
Tristan Tarrant (Commented) (JIRA)
-
Tristan Tarrant (Issue Comment Edited) (JIRA)
-
Tristan Tarrant (Updated) (JIRA)