How store java.sql.Connection in Statefull SessionBean ? 2003-11-24 - By Kalra, Ashwani
Back
best practice is to release the connection asap once its work is dont. ie
aquire the connection in method using jndi lookup of the DataSource and
close it once function is finished.
/Ashani
>-- --Original Message-- --
>From: Stefan Frank [mailto:s.frank@(protected)]
>Sent: Monday, November 24, 2003 8:43 PM
>To: J2EEPATTERNS-INTEREST@(protected)
>Subject: Re: How store java.sql.Connection  in Statefull SessionBean ?
>
>
>Why do you have a need for storing the Connection?! Storing and Reusing
>the Connection is not such a good idea if you have transactions that
>cross the boundaries of you StatefulSessionBean, with demarcations
>declared in your deployment-desriptors - which is one of the mayor
>reasons to have SessionBeans instead of a simple Class. Usually the
>Connection should be managed by the Container. The Container is also
>responsible for pooling the connection, so that you will not see any
>performance-penalties with this approach. Or is there a
>specififc reason
>why you want to acquire, manage and store the Connection inside the
>Stateful Session Bean?!
>
>Paolo Bacco wrote:
>> Hi all,
>> I deal with an old J2EE container (OAS), EJB 1.0 specs
>compliant, which
>> allows to create only statefull Session Beans.
>> I tried to create a simple application where each session
>bean holds its
>> own connection to database (so it performs commit/rollback operation
>> according client requests).
>> My question is how manage Connection in my Statefull Bean.
>> I know that java.sql.Connection has to be declared as
>transient member,
>> because Session Bean could be passivated by container, so how could I
>> prevent loosing connection?
>> I guess that a solution is to give that connection to another
>> object in EjbPassivate() method and acquire it in EjbActivate(), but
>> neither I can store any object in EjbSessionContext, nor I can store
>> Connection in JNDI service (because is not serializable again).
>> Someone can help me?
>>
>> Thanks,
>> Paolo Bacco - Italy
>> ====================================================================
>> Companion Site: http://www.corej2eepatterns.com J2EE BluePrints:
>> http://java.sun.com/blueprints/corej2eepatterns List Archive:
>> http://archives.java.sun.com/archives/j2eepatterns-interest.html
>> Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
>> listserv@(protected)
>
>====================================================================
>Companion Site: http://www.corej2eepatterns.com
>J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
>List Archive:
>http://archives.java.sun.com/archives/j2eepatterns-interest.htm
l
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to
listserv@(protected)
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____
This message contains information that may be privileged or confidential and
is the property of the Cap Gemini Ernst & Young Group. It is intended only
for the person to whom it is addressed. If you are not the intended
recipient, you are not authorised to read, print, retain, copy, disseminate,
distribute, or use this message or any part thereof. If you receive this
message in error, please notify the sender immediately and delete all copies
of this message.
====================================================================
Companion Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
