BMP Entity EJB and JDBC Connection

[Mihal Badjonski]

In my BMP Entity Bean class I have a
java.sql.Connection attribute. I initialize this
attribute in the setEntityContext method. Here I use
a JNDI lookup to obtain the reference of the connection
pool and from the connection pool I get a
java.sql.Connection object. In the method
unsetEntityContext I call the method connection.close().
I use a Cloudscape evaluation database that comes
with Weblogic 5.1.

I have seen this solution in J2EE Tutorial at
http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/BMP.html
This solution is also in accordance with the
article “Seven Rules for Optimizing Entity Beans“ at
http://developer.java.sun.com/developer/technicalArticles/ebeans/sevenrules/
(rule 4).

However, it seems that Weblogic 5.1 does not support such a
solution. When I run my client program for the first time,
everything is OK. But when I start my client program one more
time, I get the following exception on the server side:

java.sql.SQLException: java.lang.NullPointerException
at weblogic.jdbc20.rmi.SerialConnection.prepareStatement
(SerialConnection.java:61)
.at ...

It seems that BMP Entity Bean in Weblogic looses the
connection when it goes from READY state to POOLED state
and then back to READY state again.

It’s interesting that a Weblogic 5.1 example (at
\weblogic\examples\ejb\basic\beanManaged) uses JNDI
lookup and DataSource.getConnection() in every method
where the database access occurs. Such a solution is too
costly and not in accordance with the suggestions
from Sun.

And finally, here are my questions: Why do I need to call
DataSource.getConnection() in every method accessing the
database when I use Weblogic? Is it a bug or a feature?
Does Entity Bean object in Weblogic loose the
java.sql.Connection when it changes the state
(READY -> POOLED -> READY)?

[Dimitri Rakitine]

You can cache results of a JNDI lookup (datasource for example), but
storing database connection in your bean instance variable is probably
not a very good idea - first, depending on number of beans in memory,
you can run out of connections, and, second, transactions support
depends on the fact that beans call datasource.getConnection().

Mihal Badjonski <m...@datenknecht.de> wrote:

--
Dimitri