[JBoss JIRA] Created: (JGRP-1002) Merge: make the coordinator remain the same if possible after a merge
by Bela Ban (JIRA)
Merge: make the coordinator remain the same if possible after a merge
---------------------------------------------------------------------
Key: JGRP-1002
URL: https://jira.jboss.org/jira/browse/JGRP-1002
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.0
When we have {C, A, B} and split into {C,A} and {B}, then a merge will produce {A,B,C}. Therefore the coord is moved from C to A. For certain apps, e.g. JBoss singletons, this is not good, as we're moving the singleton services from a perfectly healthy node to a different node.
GOAL: come up with a deterministic policy of picking a coord such that we minimize coord switching if the existing coord is still member of the cluster.
This depends on or is related to the flexible coord pick policy JIRA issue
--
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
14 years, 6 months
[JBoss JIRA] Created: (JBAS-8698) Datasource XAExceptions leads to corrupt Transaction Context on thread
by Anders Welen (JIRA)
Datasource XAExceptions leads to corrupt Transaction Context on thread
----------------------------------------------------------------------
Key: JBAS-8698
URL: https://jira.jboss.org/browse/JBAS-8698
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: ClassLoading, Remoting, Transaction Manager Integration (Arjuna)
Affects Versions: 6.0.0.CR1, JBossAS-5.1.0.GA, JBossAS-4.2.1.GA
Reporter: Anders Welen
Assignee: Scott Stark
Attachments: TestCase3850.tar
When MySQL throws a "com.mysql.jdbc.jdbc2.optional.MysqlXAException" when called from a remote client the server thread doesn't seem to be cleaned up of transaction context data. All calls that reusing the thread will fail with the following exception:
org.jboss.util.NestedSQLException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000002:e137:4cf78939:68 status: ActionStatus.COMMITTING >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: 7f000002:e137:4cf78939:68 status: ActionStatus.COMMITTING >)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
at se.redpill.TestCase3850Bean.runTest(TestCase3850Bean.java:22)
...
...
...
>From what I can see the "MysqlXAException" (implements XAException) will not be caught in "com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.java". (Can it be some kind of classloading problem?) As the result the thread will not be cleaned of transaction information and "broken" when reused.
This seems only to occur for remote clients (If the client calls within the JVM it seems to work)
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 6 months