[esb-issues] [JBoss JIRA] Closed: (JBESB-1050) DBMessageStoreImpl: Cannot change transaction isolation level in the middle of a transaction. Postgres
Kurt Stam (JIRA)
jira-events at lists.jboss.org
Wed Oct 17 15:09:03 EDT 2007
[ http://jira.jboss.com/jira/browse/JBESB-1050?page=all ]
Kurt Stam closed JBESB-1050.
----------------------------
Resolution: Rejected
1. The issue does not show up when I use the c3p0 connection pool.
2. You're supposed to use a no-tx-datasource like so
<datasources>
<no-tx-datasource>
<jndi-name>JBossESBDS</jndi-name>
<connection-url>jdbc:postgresql://localhost:5432/jbossesb</connection-url>
<driver-class>org.postgresql.Driver</driver-class>
<user-name>postgres</user-name>
<password>postgres</password>
<metadata>
<type-mapping>PostgreSQL 8.2</type-mapping>
</metadata>
<check-valid-connection-sql>SELECT 1+1</check-valid-connection-sql>
</no-tx-datasource>
</datasources>
but even then the DEBUG statement shows up. But we're NOT in the middle of a transaction.
I'm happy to change the code, but I think this is some postgres config issue.
> DBMessageStoreImpl: Cannot change transaction isolation level in the middle of a transaction. Postgres
> ------------------------------------------------------------------------------------------------------
>
> Key: JBESB-1050
> URL: http://jira.jboss.com/jira/browse/JBESB-1050
> Project: JBoss ESB
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Message Store
> Reporter: Daniel Bevenius
> Assigned To: Kurt Stam
> Priority: Minor
> Fix For: 4.2.1 IR2
>
> Attachments: postgresql-8.2-506.jdbc3.jar
>
>
> We have been seeing this DEBUG level message when we have more then one message with the same classification in the message store:
> 2007-09-14 10:08:05,376 DEBUG [org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl]
> Deadlocks may occur under normal processing
> 2007-09-14 10:08:05,376 DEBUG [org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl]
> Cannot change transaction isolation level in the middle of a transaction.
> org.postgresql.util.PSQLException: Cannot change transaction isolation level in the middle of a tran
> saction.
> at org.postgresql.jdbc2.AbstractJdbc2Connection.setTransactionIsolation(AbstractJdbc2Connection.
> java:733)
> at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.setJdbcTransactionIsolation(Base
> WrapperManagedConnection.java:534)
> at org.jboss.resource.adapter.jdbc.WrappedConnection.setTransactionIsolation(WrappedConnection.j
> ava:390)
> at org.jboss.internal.soa.esb.persistence.format.db.DBMessageStoreImpl.redeliver(DBMessageStoreI
> mpl.java:318)
> at org.jboss.soa.esb.actions.MessageRedeliverer.process(MessageRedeliverer.java:74)
> at org.jboss.soa.esb.listeners.message.ActionProcessingPipeline.process(ActionProcessingPipeline
> .java:265)
> at org.jboss.soa.esb.listeners.ScheduleListener.onSchedule(ScheduleListener.java:108)
> at org.jboss.soa.esb.schedule.ScheduleProvider$ESBScheduledJob.execute(ScheduleProvider.java:212
> )
> at org.quartz.core.JobRunShell.run(JobRunShell.java:202)
> The code lines above might not directly match the ones in the current trunk as I've made a few modifications locally to support a simple redelivery of messages described in this dev forum thread: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=116023&start=10
> This following line of code in the redeliver method is causing this message:
> con = mgr.getConnection();
> con.setAutoCommit(false);
> con.setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED);
>
> The redeliver method is called by MessageRedeliverer action. The first message uid is successful but the second call will log the above message.
> But I do think that this will be an issue when using postgres.
> Some info about postgres and its transaction isolation levels:
> Quote:
> "In postgres, you can use all four possible transaction isolation levels. Internally, there are only two distinct isolation levels, which
> correspond to the levels Read Committed and Serializable. When you select the level Read
> Uncommitted you actually get Read Committed, and when you select Repeatable Read you really get Serializable, so the actual isolation
> level may be stricter than what you select."
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the esb-issues
mailing list