Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problems using XA Driver in AppServer when looking up a Connection (like JDBC-86) [JDBC131] #172

Closed
firebird-automations opened this issue Dec 30, 2008 · 12 comments

Comments

@firebird-automations
Copy link

Submitted by: Torsten Strasser (strator)

Is related to JDBC86
Relate to JDBC176

When getting a connection from a XA datasource retrieved via a JNDI lookup within an ejb, exceptions like in JDBC86 occure. The solution is to
not close the connection (i. e. in a finally block) after finishing the operations. In my opinion, in a managed environment like in an
appsever where connection pooling is used, the close-operation should do nothing and it should definitly not cause an exception.

@firebird-automations
Copy link
Author

Commented by: Roman Rokytskyy (rrokytskyy)

Can you describe your configuration? I.e. how did you configure the Glassfish, etc. In general it should be possible to close the connection in a finally block, and in this case connection will be returned back to the pool...

@firebird-automations
Copy link
Author

Commented by: Torsten Strasser (strator)

I deployed a connection pool with the following settings:

Datasource classname: org.firebirdsql.pool.sun.AppServerXADataSource
Resource Type: javax.sql.XADataSource

Pool-size: 8 - 64

databaseName: <//localhost:3050/C:\development\projects\stuff\xxxx.FDB>
userName: SYSDBA
JDBC30DataSource: true
type: TYPE4
password: masterkey

The datasource is looked up by an POJO class via JNDI which lives inside an stateles EJB (in this case I don't use dependency injection).
Inside the class some SELECT-statements are executed and the connection is closed in a finally block.

This szenario gives the same errors like described in JDBC 86. When I remove the code for closing the connection, it runs without problems, but
I don't really feel good with this workaround because the same code is also used outside an JEE container.

It doesn't matter if I use the XA driver or the usual pooling driver. The only driver which works is the org.firebirdsql.pool.sun.AppServerDataSource.
That's why I assume, that the connection is not returned to the pool when it is closed.

When I use the resource adapter (I deployed the RAR into glassfish) and use it as a datasource with XA transactions, it also runs without
problems.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

assignee: Roman Rokytskyy [ rrokytskyy ] => Mark Rotteveel [ avalanche1979 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue is related to JDBC86 [ JDBC86 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Fix Version: Jaybird 2.2 [ 10053 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

Link: This issue relate to JDBC176 [ JDBC176 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

summary: Problems using XY Driver in AppServer when looking up a Connection (like JDBC86) => Problems using XA Driver in AppServer when looking up a Connection (like JDBC86)

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => In Progress [ 3 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: In Progress [ 3 ] => Open [ 1 ]

@firebird-automations
Copy link
Author

Commented by: @mrotteveel

Resolved by JDBC176 if you replace the current XADataSource with org.firebirdsql.ds.FBXADataSource. The implementations in org.firebirdsql.pool and org.firebirdsql.pool.sun won't be fixed and may be removed in Jaybird 2.3 or later.

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Won't Fix [ 2 ]

@firebird-automations
Copy link
Author

Modified by: @mrotteveel

status: Resolved [ 5 ] => Closed [ 6 ]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment