Trying to convert oracle-service.xml to oracle-ds.xml in 3.2

[kyleyj]

I've got my oracle-ds working to the point where I can make a connection by taking the oracle-ds.xml and adding my jndi and url information. However, I'm not sure how to configure the connection pool manager. Currently, after the create() method of the EJB is called, an Exception is thrown -- "Successfully closed a connection for you.....". My application is handling the connection pool (creating, closing) and was specified in the oracle-service.xml. I'm not sure how to specify the same information in the oracle-ds.xml format.

Cheers!
Kyley

[ioparra]

It seems that 3.2.1 checks all opened connections and closes them for you before committing a transaction. I like this feature ALOT.

It seems you're missing a connection. Are you sure that you opening your connection in a try block and closing it in a finally block? The Exception should be throwing a stack trace with a statement saying Proxy3422.someCall. SomeCall must've started and transaction, opened a connection without closing it.

I recently converted to 3.2.1 from 3.0.4 and found all my connection leaks this way(only 1 though :) ...

-Ivan

[kyleyj]

I've got a stateful session bean in which my connection remains open until the EJB is removed. Are you saying that JBoss 3.2.1 no longer supports this? Or have I misunderstood something from the J2EE standard in what I can do within my stateful session bean?

The overhead in having to recreate the connection each time a method is called seems a bit too much.

Any thoughts?

Thanks for your feedback.
Kyley

[ioparra]

Oh. So that would explain it. I'm assuming that your grabbing your datasource and allocating a connection and storing it in a member variable. I'd also assume your resetting this connection during activation/passivation.

The problem occurs because:
1)the container is beginning a transaction
2)ejbCreate allocates a connection , this step automatically associates this new connection with the current transaction
3)when the container attempts to commit the transactions, finds that your connection is not closed, closes it for you and complains.

First: I've never felt that getting a new connection was a big overhead. I prefer to allow the datasource to handle connection pooling for me. The datasource you recieve should be pooling your connection and never truly closes them. This DS is also the gateway to JBoss JCA framework. When you do a ds.getConnection(), your not guarenteed to get a NEW connection; but instead, a connection from a previously allocated managed connection that exists in a DB pool. Because of that, getConnection is relatively cheap. The only costs are 1)security, 2)transaction, 3)overhead of allocating a new connection only if one is not available at that time.

Second: If you plan to have any sort of transactional state in your EJB, you must allocate a new connection so that the ApplicationServer knows what resources to commit on a successful call. Without doing a ds.getConnection(), your appserver will never know what connection to commit.
If you are not supporting transactions and choosing to cache the connection and commit it yourself when a piece of work is done, you'll need to modify your ejb-jar.xml and specify that this EJB has a NOTSUPPORTED transactional attribute on all the methods. This should tell the appserver to remove the current transaction allow you to grab 100 connections without complaints.

If you REALLY don't plan to support transactions, change your ejb-jar.xml to NOTSUPPORTED.

If you are, then you'll need to allocate/close a new connection each method. Make sure you allocate the connections correctly to avoid losing them:

Connection conn = null;
try{
conn = ds.getConnection();
....
}finally{
if(conn != null) try{ conn.close(); } ...
}


G/L, hopefully this answers your Qs.

-Ivan

[ioparra]

Check out this posting for more information.

http://www.jboss.org/modules/bb/index.html?module=bb&op=viewtopic&t= developer was also allocating a connection during ejbCreate.

[kyleyj]

Thank you for the great response!

Due to the fact that I am doing transaction, it sounds as if I should be getting and closing a connection within each method. All is well for me to make those changes with one exception. Due to the fact that one of the methods can potentially return a large ResultSet, I've split up the fetching of the data from the ResultSet into three methods: 1) create ResultSet 2) fetch n items from ResultSet 3) close ResultSet. The reason for this is to 2 fold, 1) orginally with Oracle 7 (with integrated AS) the size of the result was too large for one method 2) I can provide the user with intermittent data while the fetching continues. With all of that in mind, is it possible to keep the connection open across these three methods?

I thought that I could if I specified in the ejb-jar.xml file the following for the three methods:

<container-transaction>

<ejb-name>myEJB</ejb-name>
<method-name>listFrames</method-name>

....
<trans-attribute>NotSupported</trans-attribute>
</container-transaction>

However, that didn't work. Is it possible to do that? and if so, is there a way using the jmx-console to show that these methods are NotSupported rather than the Required used for the remaining methods?

Cheers!
Kyley

[borislav]

Hi kyleyj,
I've got the same problem.. I set transactions to 'bean managed' and I still have the same exception.. If you find a solution please let me know..

[ioparra]

I don't think the ejb-jar.xml does the correct mapping when it deals with standard ejb calls. IE. If you map a certain transaction/security constraint to "create", I don't think it maps to "ejbCreate".

Try explicitly setting the method <method-name>ejbCreate</method-name> to NotSupported instead of "create" That may do the trick. I haven't scanned through the spec and don't know if its a EJB thing or not.

-Ivan

[kyleyj]

Unfortunately, it looks as if the "NotSupported" flag does not prevent the Connection from being closed. I've tried adding the transaction/security constraint to several other methods in addition to "create" and "ejbCreate" and it still complains that a connection has been closed for you.

Has anyone been able to retain a Connection across methods in a Stateful Session Bean with 3.2.1? Should I report a bug, or am I still not doing something right?

Cheers!
Kyley

[kyleyj]

By changing the "SpecCompliant" tag in the transaction-service.xml file I am able to retain the Connection throughout the lifetime of my EJB instance. However, JBoss is now complaining that "Destroying connection that could not be successfully matched:".

I'm wondering what this message means. I'm creating and closing the connection after each method call (except for those mentioned previously) and I'm still getting these warnings.

[ioparra]

Where are you getting these errors? When you are closing a connection that was opened in the current transaction or the closing of a connection during ejbRemove/passivate?

The only "matching" I can think of is during JCA connection allocation. ManagedConnection.matchConnection().... I think. Can you attach a stack trace?

-Ivan

[kyleyj]

Within my application I attach to several different EJBs. I seem to be getting the errors when I switch between the EJBs. For instance, I call A.method and then B.method and I get the warning.

As to the closing of the connection, I'm closing the connection after each transaction, not during ejbCreate/ejbRemove.

The warning doesn't print the stack trace. I would have to build it from the sources and put Thread.dumpStack() manually when the WARNING message is generated. Would that provide any better help? I can do that if that would be helpful.

Cheers,
Kyley