[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called before all persistence units have performed database updates
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow updated WFLY-3619:
-------------------------------
Summary: XA END / un-enlist for database connection called before all persistence units have performed database updates (was: XA END / un-enlist for database connection called to early)
> XA END / un-enlist for database connection called before all persistence units have performed database updates
> --------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log
>
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-3619) XA END / un-enlist for database connection called to early
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-3619?page=com.atlassian.jira.plugin.... ]
Scott Marlow reopened WFLY-3619:
--------------------------------
reopening for tracking purposes
> XA END / un-enlist for database connection called to early
> ----------------------------------------------------------
>
> Key: WFLY-3619
> URL: https://issues.jboss.org/browse/WFLY-3619
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB, JCA, JPA / Hibernate, Transactions
> Affects Versions: 8.0.0.Final
> Environment: Windows 7 64-bit
> JDK 1.8.0_05-b13 64-Bit
> MS SQL Server 2012 database
> Latest MS JDBC driver
> XA datasource
> Reporter: Andreas Liebscher
> Assignee: Scott Marlow
> Priority: Blocker
> Attachments: persistence.xml, server-9.0.0.Alpha1-SNAPHOT-trace.log, server-9.0.0.Alpha1-SNAPHOT.log, server-all-traces-full.log.gz, server-org-jboss-as-jpa.log, server.jca.log, server_MSSQL_Trace.log
>
>
> While trying to port an EE application from JBoss5 to WF8 the following problem occurred:
> EJBs (@Required) using JPA to do some data changes.
> Some changes get already written to the database, others reside in the session cache.
> After the top EJB call returns, a Hibernate Session flush is triggered in beforeCompletion.
> Then more changes are flushed to the database, but I run in a reproduceable database locking problem.
> After some time an update of a row fails with lock wait timeout. This row has been inserted prior during the EJB call.
> There should be exactly one xa transaction active processing all data changes.
> But the database shows two active session, one is an xa transaction with sessionId -2 (orphaned), the other session is a local transaction.
> After analyzing all database communication with the help of the JDBC driver logging I found the following behaviour:
> - a connection is enlisted and xa start called
> - the same connection is used for several select / insert / update statements
> - after return of the top EJB call on the same connection xa end and connection un-enlist is called
> - the same connection is used for session flush (beforeCompletion) but with local transaction because the connection is no longer associated with the xa transaction, so locks can be expected.
> Shouldn't xa end be called AFTER beforeCompletion / session flush!?!
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1109691|https://bugzilla.redhat.com/show_bug.cgi?id=1109691] from ASSIGNED to CLOSED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1109691|https://bugzilla.redhat.com/show_bug.cgi?id=1109691] from CLOSED to ASSIGNED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-3805) JGroupsBroadcastGroupConfiguration Serialization Problem
by Yong Hao Gao (JIRA)
Yong Hao Gao created WFLY-3805:
----------------------------------
Summary: JGroupsBroadcastGroupConfiguration Serialization Problem
Key: WFLY-3805
URL: https://issues.jboss.org/browse/WFLY-3805
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Yong Hao Gao
Assignee: Yong Hao Gao
When configuring JMS connection factories using jgroups discovery group, the client will get serialization exceptions because we pass a JChannel which is not serializable.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (WFLY-3189) Error validating jboss-ejb3.xml.
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-3189?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen commented on WFLY-3189:
-------------------------------------------
ah yes for the eclipse based ones but if I understood you correctly you were pointing at issues in the xsd too ?
but we can start with the suggested fix on eclipse and work from there.
> Error validating jboss-ejb3.xml.
> --------------------------------
>
> Key: WFLY-3189
> URL: https://issues.jboss.org/browse/WFLY-3189
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Final
> Environment: WildFly 8.0.0.Final
> Reporter: shinzey shinzey
> Assignee: David Lloyd
> Attachments: p.patch
>
>
> I'm trying to configure code completion for jboss-ejb3.xml with schema, but fail to do that due to the following validation error:
> {noformat}
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-beanType' to a(n) 'type definition' component. [33]
> src-resolve: Cannot resolve the name 'javaee:jboss-ejb-jarType' to a(n) 'type definition' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-enterprise-beansType' to a(n) 'type definition' component. [37]
> src-resolve: Cannot resolve the name 'javaee:assembly-descriptor-entry' to a(n) 'element declaration' component. [35]
> src-resolve: Cannot resolve the name 'javaee:jboss-assembly-descriptor-bean-entryType' to a(n) 'type definition' component. [39]
> {noformat}
> The jboss-ejb3.xml is quite simple:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss:ejb-jar version="3.1" impl-version="2.0"
> xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:jboss="http://www.jboss.com/xml/ns/javaee"
> xmlns:s="urn:security:1.1"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd
> http://www.jboss.com/xml/ns/javaee http://www.jboss.org/j2ee/schema/jboss-ejb3-2_0.xsd">
> <assembly-descriptor>
> <s:security>
> <ejb-name>*</ejb-name>
> <s:security-domain>testsd</s:security-domain>
> </s:security>
> </assembly-descriptor>
> </jboss:ejb-jar>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Jesper Pedersen <jpederse(a)redhat.com> changed the Status of [bug 1109691|https://bugzilla.redhat.com/show_bug.cgi?id=1109691] from ASSIGNED to CLOSED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months
[JBoss JIRA] (JBJCA-1181) Recovery is not run for XA datasource which does not define password under <security>
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1181?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on JBJCA-1181:
------------------------------------------------
Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1107991|https://bugzilla.redhat.com/show_bug.cgi?id=1107991] from CLOSED to ASSIGNED
> Recovery is not run for XA datasource which does not define password under <security>
> -------------------------------------------------------------------------------------
>
> Key: JBJCA-1181
> URL: https://issues.jboss.org/browse/JBJCA-1181
> Project: IronJacamar
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Deployer
> Affects Versions: 1.0.26.Final, 1.1.6.Final, 1.2.0.Beta2
> Reporter: Ondřej Chaloupka
> Assignee: Jesper Pedersen
> Fix For: 1.0.27.Final, 1.2.0.Beta4
>
> Attachments: server.log
>
>
> If you do not define password for xa datsource then recovery does not run despite the fact that there is no need of password for connection to database.
> When you define just:
> {code}
> <security>
> <user-name>crashrec</user-name>
> </security>
> {code}
> and database is set to not require password - e.g. for postgres
> vim /var/lib/pgsql/data/pg_hba.conf
> you define connection with 'trust'
> host all all 127.0.0.1/32 trust
> Then you will experience WARNING message during recovery and recovery itself on the xa datasource is not run
> {code}
> 10:12:58,137 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000904: No security domain defined for crash recovery: java:jboss/xa-datasources/CrashRecoveryDS
> 10:12:58,138 WARN [org.jboss.jca.core.tx.jbossts.XAResourceRecoveryImpl] (Periodic Recovery) IJ000905: Subject for crash recovery was null: java:jboss/xa-datasources/CrashRecoveryDS
> {code}
> Whole configuration of xa-datasource used:
> {code}
> <xa-datasource jndi-name="java:jboss/xa-datasources/CrashRecoveryDS" pool-name="CrashRecoveryDS" enabled="true" use-java-context="true">
> <xa-datasource-property name="DatabaseName">crashrec</xa-datasource-property>
> <xa-datasource-property name="PortNumber">5432</xa-datasource-property>
> <xa-datasource-property name="ServerName">127.0.0.1</xa-datasource-property>
> <xa-datasource-class>org.postgresql.xa.PGXADataSource</xa-datasource-class>
> <driver>postgres</driver>
> <transaction-isolation>TRANSACTION_READ_COMMITTED</transaction-isolation>
> <xa-pool>
> <min-pool-size>5</min-pool-size>
> <max-pool-size>50</max-pool-size>
> </xa-pool>
> <security>
> <user-name>crashrec</user-name>
> </security>
> <recovery>
> <!--
> <recover-credential>
> <user-name>crashrec</user-name>
> </recover-credential>
> -->
> </recovery>
> <validation>
> <valid-connection-checker class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker"/>
> <exception-sorter class-name="org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter"/>
> </validation>
> <timeout>
> <blocking-timeout-millis>30000</blocking-timeout-millis>
> <idle-timeout-minutes>15</idle-timeout-minutes>
> </timeout>
> <statement>
> <prepared-statement-cache-size>75</prepared-statement-cache-size>
> </statement>
> </xa-datasource>
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 10 months