[JBoss JIRA] (JBTM-2725) Race condition in ControlWrapper
by Tomasz Adamski (JIRA)
[ https://issues.jboss.org/browse/JBTM-2725?page=com.atlassian.jira.plugin.... ]
Tomasz Adamski edited comment on JBTM-2725 at 8/12/16 7:35 AM:
---------------------------------------------------------------
Hey,
I usually edit the description after creating JIRA - it is already here ;)
There are lot of ControlWrapper objects created so synchronized on it's rollback method is not effective. I have synchronized the code on the ControlImple object which (to my understanding) is shared during the whole transaction. After this change the error does not occur.
was (Author: tomekadamski):
Hey,
I usually edit the description after creating JIRA - it is already here ;)
Ehh, those errors are intermittent and I hoped this would be the last fix to stop them but unfortunately got another one even with synchronized block - I'm looking at the issue further :/
OK - there is lot of ControlWrappers created so synchronized on it's rollback method was not effective. I have synchronized the code on the ControlImple object which (to my understanding) is shared during the whole transaction. After this change the error does not occur.
> Race condition in ControlWrapper
> --------------------------------
>
> Key: JBTM-2725
> URL: https://issues.jboss.org/browse/JBTM-2725
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: JTS
> Affects Versions: 5.3.3.Final
> Reporter: Tomasz Adamski
> Assignee: Tomasz Adamski
>
> I have encountered another problem during timeout induced rollback scenario. When the thread rolls back the transaction immediately after the reaper they both end in ControlWrapper#rollback method. This should be synchronized: if it is not both threads may call TransactionImple#rollback method which is not expected and leads to IllegalStateException error. In synchronized scenario second thread in ControlWrapper#rollback method see that the TransactionImple has already been disassociated with the thread and throws TRANSACTION_ROLLEDBACK exception which is expected.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBTM-2692) Narayana OSGi bundle is missing optional packages
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2692?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2692:
--------------------------------
Issue Type: Bug (was: Feature Request)
> Narayana OSGi bundle is missing optional packages
> -------------------------------------------------
>
> Key: JBTM-2692
> URL: https://issues.jboss.org/browse/JBTM-2692
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Affects Versions: 5.3.3.Final
> Reporter: Guillaume Nodet
> Assignee: Amos Feng
> Priority: Blocker
> Fix For: 5.next
>
>
> The problem is that the annotations on @Transactional are lost, which makes this annotation unusable in a CDI environment.
> Patch below:
> {code}
> diff --git a/osgi/jta/pom.xml b/osgi/jta/pom.xml
> index 87d32c5..cd68637 100644
> --- a/osgi/jta/pom.xml
> +++ b/osgi/jta/pom.xml
> @@ -206,6 +206,9 @@
> org.apache.felix.service.command,
> org.apache.karaf.shell.api.action,
> org.apache.karaf.shell.api.action.lifecycle,
> + javax.enterprise.util;resolution:=optional,
> + javax.interceptor;resolution:=optional
> + javax.enterprise.context;resolution:=optional
> </Import-Package>
> <Embed-Transitive>true</Embed-Transitive>
> <Embed-Dependency>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months
[JBoss JIRA] (JBTM-2720) Allow the setting of an initial delay in PeriodRecovery
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2720?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2720:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Allow the setting of an initial delay in PeriodRecovery
> -------------------------------------------------------
>
> Key: JBTM-2720
> URL: https://issues.jboss.org/browse/JBTM-2720
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: Recovery
> Reporter: Matthew Robson
> Assignee: Tom Jenkinson
> Fix For: 5.next
>
>
> Currently Periodic Recovery kicks off at the same interval on every server. As a domain mode cluster grows in size, this leads to significant contention in the DB, especially for RAC implementations. Completion time goes from milliseconds with 1 server to 20+ seconds with 20+ servers.
> In an effort to avoid this, an offset the initial start of Periodic Recovery could be provided for the nodes in the cluster.
> Periodic Recovery currently leverages 2 properties:
> <system-properties>
> <property name="RecoveryEnvironmentBean.periodicRecoveryPeriod" value="120"/>
> <property name="RecoveryEnvironmentBean.recoveryBackoffPeriod" value="10"/>
> </system-properties>
> The proposal would be to add a 3rd property, 'RecoveryEnvironmentBean.periodicRecoveryInitilizationOffset' which, when set, would be used for each node. If not set, it would default to current behavior.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 7 months