BTM

race condition: potential connection leak when closing connection after transaction terminated

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.3, 1.3.1, 1.3.2
  • Fix Version/s: 1.3.3
  • Labels:
    None
  • Number of attachments :
    0

Description

When a connection is closed after the transaction in which it has been enlisted has been terminated, the connection pool must check if the connection is still enlisted in a transaction or not.

This basically means iterating all the XAResources of all in-flight transactions via the Scheduler of transactions' XAResourceManager. Since those calls are not reentrant, they can lead to an exception in a Scheduler's iterator which end up with the connection not being requeued.

See: http://www.nabble.com/Exception-during-calling-Connection-close()-to20242143.html

Issue Links

is superceded by

Bug - A problem which impairs or prevents the functions of the product. BTM-43 Fix for BTM-33 leads to another problem

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Ludovic Orban added a comment -

As a workaround, you can make sure connections are closed before the transaction commits or rolls back.

Fixing this bug will require more than just adding synchronizations: iterating all transactions will hardly ever be thread safe so this should be changed to make sure a thread never need to read data outside of its transaction context.

The exact root cause is unknown yet, the parts of the code that trigger this race condition still need to be found to be able to reproduce the bug. This must happen before any fix can be worked on.

Show
Ludovic Orban added a comment - As a workaround, you can make sure connections are closed before the transaction commits or rolls back. Fixing this bug will require more than just adding synchronizations: iterating all transactions will hardly ever be thread safe so this should be changed to make sure a thread never need to read data outside of its transaction context. The exact root cause is unknown yet, the parts of the code that trigger this race condition still need to be found to be able to reproduce the bug. This must happen before any fix can be worked on.
Hide
Permalink
Ludovic Orban added a comment -

To work around this issue when using Hibernate, make sure the hibernate.connection.release_mode parameter is set to after_statement. This will force Hibernate to release the connections to the pool as soon as possible.

Show
Ludovic Orban added a comment - To work around this issue when using Hibernate, make sure the hibernate.connection.release_mode parameter is set to after_statement. This will force Hibernate to release the connections to the pool as soon as possible.
Hide
Permalink
Ludovic Orban added a comment - - edited

Issue solved in trunk.

You can download a snapshot distribution from here: http://snapshots.dist.codehaus.org/btm/btm-dist-1.3.3-20081115.zip
or the BTM JAR from here: http://snapshots.repository.codehaus.org/org/codehaus/btm/btm/1.3.3-20081115/btm-1.3.3-20081115.jar

Show
Ludovic Orban added a comment - - edited Issue solved in trunk. You can download a snapshot distribution from here: http://snapshots.dist.codehaus.org/btm/btm-dist-1.3.3-20081115.zip or the BTM JAR from here: http://snapshots.repository.codehaus.org/org/codehaus/btm/btm/1.3.3-20081115/btm-1.3.3-20081115.jar
Hide
Permalink
Ludovic Orban added a comment -

Looks like the root problem hasn't been fixed after all: http://www.nabble.com/Fix-for-BTM-33-leads-to-another-problem-td22285282.html

Show
Ludovic Orban added a comment - Looks like the root problem hasn't been fixed after all: http://www.nabble.com/Fix-for-BTM-33-leads-to-another-problem-td22285282.html
Hide
Permalink
Ludovic Orban added a comment -

This issue has been solved in BTM-43.

Show
Ludovic Orban added a comment - This issue has been solved in BTM-43 .

People

  • Assignee:
    Ludovic Orban
    Reporter:
    Ludovic Orban
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: