[JBoss JIRA] (JGRP-2362) Providing logical member name in JDBC_PING
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2362?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2362:
--------------------------------
I fail to understand what your problem is. Can you illustrate this with a setp-by-step example?
> Providing logical member name in JDBC_PING
> ------------------------------------------
>
> Key: JGRP-2362
> URL: https://issues.jboss.org/browse/JGRP-2362
> Project: JGroups
> Issue Type: Feature Request
> Affects Versions: 4.0.17, 4.0.18, 4.0.19, 4.1.0, 4.0.20
> Reporter: S Pokutniy
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 4.1.2
>
>
> When using JDBC_PING and logical names instead of UUIDs and one of the cluster member crashes or get killed and this member is not coordinator then its database set still remains in the database as long as coordinator changes (independently from remove_old_coords_on_view_change /remove_all_data_on_view_change). If the the cluster is then restarted the old dataset makes connect() much slower (+30 seconds), as the members seem to be tryting to connect to it. Parameter remove_all_data_on_view_change seems to be the solution but it does not work as long as coordinator does not change, so practically the same as remove_old_coords_on_view_change.
> The only solution seems to be to provide an appropriate delete statement in parameter initialize_sql, which would delete old entry, for example like this: delete from JGROUPSPING where ping_data like '%logical name%'. However, this is neither really quick nor the ideal solution, as ping_data's datatype is bytea or bit varying.
> It would be great to have also logical name in JGROUPSPING, which is instead per default in insert(). This is also easy to implement as there is access to this information in PingData.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2361) Error related to Jgroup and Database connection is getting reset
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2361?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2361 at 7/31/19 7:09 AM:
---------------------------------------------------------
Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config (jgroups-tcp.xml)?
was (Author: belaban):
Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config?
> Error related to Jgroup and Database connection is getting reset
> ----------------------------------------------------------------
>
> Key: JGRP-2361
> URL: https://issues.jboss.org/browse/JGRP-2361
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Environment: Hybris running on tomcat - Centos 7
> Reporter: karthikeyan Aruljothi
> Assignee: Bela Ban
> Priority: Major
> Attachments: Jgroup error in preprod-000.txt, Jgroups blocking and terminating connection.txt, Jgroups error in console.txt, error Jgroups.txt
>
>
> Hi ,
> we are facing an issue with our cluster configuration and due to this JVM responding time also takes more time, after clearing the cache / restarting all nodes application works as expected.
> When issue arises one of the core occupies 100% cpu utilization then it confirms to restart the server otherwise it never process any request. Below is our configuration in local.properties. Also providing error logs as attachment. could see error in logs related to Jgroups blocking and connection getting terminated between nodes.
> Let us know your valuable inputs, on what exactly the issue i.e causing the slowness then blocking the whole server.
> Attached cluster configuration for each nodes and error logs
> Adding to this we are getting below error while doing deployment/restarting of servers
> WARN [localhost-startStop-1] [GMS] hybrisnode-0: JOIN(hybrisnode-0) sent to hybrisnode-2 timed out (after 3000 ms), on try 3
> WARN [pool-3-thread-1] [GMS] hybrisnode-3: JOIN(hybrisnode-3) sent to hybrisnode-1 timed out (after 3000 ms), on try 4
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2361) Error related to Jgroup and Database connection is getting reset
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2361?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2361:
--------------------------------
Could be that you're running different versions of JGroups (cookie sent by /172.26.235.231:43565 does not match own cookie; terminating connection). What's your JGroups config?
> Error related to Jgroup and Database connection is getting reset
> ----------------------------------------------------------------
>
> Key: JGRP-2361
> URL: https://issues.jboss.org/browse/JGRP-2361
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.11
> Environment: Hybris running on tomcat - Centos 7
> Reporter: karthikeyan Aruljothi
> Assignee: Bela Ban
> Priority: Major
> Attachments: Jgroup error in preprod-000.txt, Jgroups blocking and terminating connection.txt, Jgroups error in console.txt, error Jgroups.txt
>
>
> Hi ,
> we are facing an issue with our cluster configuration and due to this JVM responding time also takes more time, after clearing the cache / restarting all nodes application works as expected.
> When issue arises one of the core occupies 100% cpu utilization then it confirms to restart the server otherwise it never process any request. Below is our configuration in local.properties. Also providing error logs as attachment. could see error in logs related to Jgroups blocking and connection getting terminated between nodes.
> Let us know your valuable inputs, on what exactly the issue i.e causing the slowness then blocking the whole server.
> Attached cluster configuration for each nodes and error logs
> Adding to this we are getting below error while doing deployment/restarting of servers
> WARN [localhost-startStop-1] [GMS] hybrisnode-0: JOIN(hybrisnode-0) sent to hybrisnode-2 timed out (after 3000 ms), on try 3
> WARN [pool-3-thread-1] [GMS] hybrisnode-3: JOIN(hybrisnode-3) sent to hybrisnode-1 timed out (after 3000 ms), on try 4
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
Richard Opalka commented on WFCORE-4525:
----------------------------------------
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Assignee: James Perkins
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFCORE-4525) Fix failing tests on IBM JDK
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFCORE-4525?page=com.atlassian.jira.plugi... ]
Richard Opalka edited comment on WFCORE-4525 at 7/31/19 6:54 AM:
-----------------------------------------------------------------
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
was (Author: ropalka):
SilentModeTestCase started to pass in IBM JDK [~jamezp].
You meant that both
* CLIEmbedHostControllerTestCase
* CLIEmbedServerTestCase
should be annotated with @Ignore if IBM JDK is detected?
> Fix failing tests on IBM JDK
> ----------------------------
>
> Key: WFCORE-4525
> URL: https://issues.jboss.org/browse/WFCORE-4525
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: Richard Opalka
> Assignee: James Perkins
> Priority: Major
> Attachments: forked-booter.png, ibm-jdk8.png, oracle-jdk.png
>
>
> The following tests are failing on latest IBM JDK 8:
> ---
> # testsuite/standalone
> SilentModeTestCase
> # testsuite/manualmode
> CLIEmbedHostControllerTestCase
> CLIEmbedServerTestCase
> ---
> Tested on:
> ---
> java version "1.8.0_211"
> Java(TM) SE Runtime Environment (build 8.0.5.36 - pxa6480sr5fp36-20190510_01(SR5 FP36))
> IBM J9 VM (build 2.9, JRE 1.8.0 Linux amd64-64-Bit Compressed References 20190502_415899 (JIT enabled, AOT enabled)
> OpenJ9 - 46e57f9
> OMR - 06a046a
> IBM - 0b909bf)
> JCL - 20190409_01 based on Oracle jdk8u211-b25
> ---
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (JGRP-2364) simply lock and unlock JGroups lock repeatedly will create chaos
by Yong Deng (Jira)
[ https://issues.jboss.org/browse/JGRP-2364?page=com.atlassian.jira.plugin.... ]
Yong Deng commented on JGRP-2364:
---------------------------------
Following is the temporary fix on my side in org.jgroups.protocols.Locking.ClientLock#_unlock. I add 10 seconds timeout in order not to hang when we hit other JGroups bugs and RELEASE_LOCK_OK is not sent back ever.
{code:java}
protected synchronized void _unlock(boolean force) {
if(!acquired && !denied && !force)
return;
this.timeout=0;
this.is_trylock=false;
if (!denied) {
if (!force)
addToPendingReleaseRequests(this);
sendReleaseLockRequest(name, lock_id, owner);// lock will be released on RELEASE_LOCK_OK response
if (force && removeClientLock(name, owner))
notifyLockDeleted(name);
if (!force) {
//unlock will return only when get RELEASE_LOCK_OK or timeLeft after some seconds
long timeLeft = 10000;
while (acquired || denied) {
long start = System.currentTimeMillis();
try {
wait(timeLeft);
} catch (InterruptedException ie) {
break;
}
long duration = System.currentTimeMillis() - start;
if (duration > 0)
timeLeft -= duration;
if (timeLeft <= 0) {
if (log.isWarnEnabled()) {
log.warn(format("[%s]: timeout wait for RELEASE_LOCK_OK response for lock=%s", local_addr, this));
}
//defensive fix
acquired = denied = false;
break;
}
}
}
}
else
_unlockOK();
}
{code}
> simply lock and unlock JGroups lock repeatedly will create chaos
> ----------------------------------------------------------------
>
> Key: JGRP-2364
> URL: https://issues.jboss.org/browse/JGRP-2364
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 4.1.1
> Environment: JDK: 1.8
> JGroups: 4.1.1
> Lock: CENTRAL_LOCK
> Reporter: Yong Deng
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.2
>
> Attachments: LockSimpleTest.java
>
>
> I have one simple use case to reproduce the issue. In same thread, just lock/unlock the lock repeatedly. Turn the log level to TRACE, you will find the communication chaos between the client and the coordinate. *JGroups unlock will return immediately after sending out RELEASE_LOCK currently. Why unlock don’t wait and only return after receiving the RELEASE_LOCK_OK response?*
> * Current log:
> {code:java}
> 16:56:40,399 TRACE [CENTRAL_LOCK] A --> A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000]
> 16:56:40,404 TRACE [CENTRAL_LOCK] A <-- A: GRANT_LOCK[sample-lock, lock_id=1, owner=A::31, trylock, timeout=10000, sender=A]
> 16:56:40,410 TRACE [CENTRAL_LOCK] A --> A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,411 TRACE [CENTRAL_LOCK] A <-- A: LOCK_GRANTED[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,413 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A <-- A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31, sender=A]
> 16:56:40,414 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK_OK[sample-lock, lock_id=1, owner=A::31]
> 16:56:40,415 TRACE [CENTRAL_LOCK] A --> A: RELEASE_LOCK[sample-lock, lock_id=1, owner=A::31]
> {code}
> * The expected log:
> {code:java}
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,849 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] GRANT_LOCK [sample-lock, lock_id=1, owner=A::63, trylock (timeout=10000)
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,852 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] LOCK_GRANTED [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,853 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] --> [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> 2019-07-24 17:01:52,854 TRACE [org.jgroups.protocols.CENTRAL_LOCK] [A] <-- [A] RELEASE_LOCK_OK [sample-lock, lock_id=1, owner=A::63 ]
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12337?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson commented on WFLY-12337:
-----------------------------------------
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic
> Wildfly Transaction REQUIRES_NEW not working
> --------------------------------------------
>
> Key: WFLY-12337
> URL: https://issues.jboss.org/browse/WFLY-12337
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Hao Chen
> Assignee: Thomas Jenkinson
> Priority: Major
>
> We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
> The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
> This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
> Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
> But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
> And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
> So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
> Here is a trace except I captured:
> TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
> JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
> JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
> LocalUserTransaction.begin() line: 48
> ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
> LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
> ...
> ContextTransactionManager.resume(AbstractTransaction) line: 158
> LocalTransaction.resume() line: 248
> TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
> TransactionManagerImple.resume(Transaction) line: 111
> AtomicAction.resume(AtomicAction) line: 361
> LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
> TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
> UserTransactionRegistry.userTransactionStarted() line: 119
> UserTransactionListenerImpl.userTransactionStarted() line: 52
> CachedConnectionManagerImpl.userTransactionStarted() line: 249
> TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
> TxConnectionListener.enlist() line: 264
> !-- changed in ironjacamar-core-impl-1.2
> // If we are already enlisted there is no reason to check again, as this method
> // could be called multiple times during a transaction lifecycle.
> // We know that we can only be inside this method if we are allowed to
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months
[JBoss JIRA] (WFLY-12337) Wildfly Transaction REQUIRES_NEW not working
by Thomas Jenkinson (Jira)
[ https://issues.jboss.org/browse/WFLY-12337?page=com.atlassian.jira.plugin... ]
Thomas Jenkinson edited comment on WFLY-12337 at 7/31/19 6:39 AM:
------------------------------------------------------------------
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic https://developer.jboss.org/en/wildfly
was (Author: tomjenkinson):
[~maeste]do you have any ideas what this could be about? I think the TransactionDefinition is a Spring thing: https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/spri...
[~hchen00] This might be better as a discussion on the wildfly space - if you do create a topic feel free to ping Stefano and myself on the topic
> Wildfly Transaction REQUIRES_NEW not working
> --------------------------------------------
>
> Key: WFLY-12337
> URL: https://issues.jboss.org/browse/WFLY-12337
> Project: WildFly
> Issue Type: Bug
> Components: JCA, Transactions
> Affects Versions: 16.0.0.Final
> Reporter: Hao Chen
> Assignee: Thomas Jenkinson
> Priority: Major
>
> We recently upgraded from jboss-eap-6.4 to Wildfly 16. Most things worked fine until we find one issue in the case that a method that is called using TransactionTemplate with TransactionDefinition.PROPAGATION_REQUIRES_NEW is not working...
> The case is that: we use this PROPAGATION_REQUIRES_NEW transaction to commit a log of login failure, while the main transaction is rolled back due login exception.
> This used to work without problem in jboss-eap-6.4 though we were seeing warnings like:
> Trying to change transaction TransactionImple < ac, BasicAction: 0:ffff0a004b01:513406f2:5d37ce0b:2a0 status: ActionStatus.RUNNING > in enlist!
> But in Wildfly 16 PROPAGATION_REQUIRES_NEW doesn't work any more -- the new transaction seems to rolled back together with the main transaction. After spending quite some time debugging into the Wildfly/Jboss code, I found that in org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.enlist method, there is a new line:
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
> And in our case, the TxConnectionListener object is the same in the new transaction as in the old transaction, so it's already marked as "enlisted". And therefore the rest of enlist is never executed for the new transaction, so Wildfly never issued a "XA Start" command for the new transaction.
> So the question is: is the added isEnlisted() check a bug introduced or there is something wrong we did to configure Wildfly and/or Spring? How should the REUIRES_NEW case work?
> Here is a trace except I captured:
> TransactionTemplate.execute(TransactionCallback<T>) line: 130 JtaTransactionManager(AbstractPlatformTransactionManager).getTransaction(TransactionDefinition) line: 353 JtaTransactionManager(AbstractPlatformTransactionManager).handleExistingTransaction(TransactionDefinition, Object, boolean) line: 433
> JtaTransactionManager.doBegin(Object, TransactionDefinition) line: 831
> JtaTransactionManager.doJtaBegin(JtaTransactionObject, TransactionDefinition) line: 872
> LocalUserTransaction.begin() line: 48
> ContextTransactionManager.begin(CreationListener$CreatedBy) line: 62
> LocalTransactionContext.beginTransaction(int, boolean, CreationListener$CreatedBy) line: 188 JBossJTALocalTransactionProvider(JBossLocalTransactionProvider).createNewTransaction(int)
> ...
> ContextTransactionManager.resume(AbstractTransaction) line: 158
> LocalTransaction.resume() line: 248
> TransactionManagerDelegate(BaseTransactionManagerDelegate).resume(Transaction) line: 122
> TransactionManagerImple.resume(Transaction) line: 111
> AtomicAction.resume(AtomicAction) line: 361
> LocalTransaction(AbstractTransaction).notifyAssociationListeners(boolean) line: 115
> TransactionManagerService$2.associationChanged(AbstractTransaction, boolean) line: 97
> UserTransactionRegistry.userTransactionStarted() line: 119
> UserTransactionListenerImpl.userTransactionStarted() line: 52
> CachedConnectionManagerImpl.userTransactionStarted() line: 249
> TxConnectionManagerImpl.transactionStarted(Collection<ConnectionRecord>) line: 460
> TxConnectionListener.enlist() line: 264
> !-- changed in ironjacamar-core-impl-1.2
> // If we are already enlisted there is no reason to check again, as this method
> // could be called multiple times during a transaction lifecycle.
> // We know that we can only be inside this method if we are allowed to
> if (isEnlisted() || getState().equals(ConnectionState.DESTROY) || getState().equals(ConnectionState.DESTROYED))
> return;
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
6 years, 4 months