How store java.sql.Connection in Statefull SessionBean ? 2003-11-25 - By Paolo Bacco
Back
I agree with your analisi.
Thanks,
Paolo
-- -- Original Message -- --
From: "Stefan Frank" <s.frank@(protected)>
To: <J2EEPATTERNS-INTEREST@(protected)>
Sent: Tuesday, November 25, 2003 1:14 PM
Subject: Re: How store java.sql.Connection  in Statefull SessionBean ?
> Hi Paolo,
> ah, I see: 3) makes things difficult&this is where the need to acquire
> and keep the connection comes from. Correct me if I'm wrong, but does
> client need to control the commit/rollback really on the CONNECTION?!
> Maybe things will become easier when you just map the commit/rollback on
> the BusinessObjects: Gather the Objects that need to be stored in the
> StatefulSessionBean, if user commits, acquire a connection from the
> server, store, commit and release the connection, if the User wants to
> rollback, just discard the stored Objects. Activating/passivating will
> become less troublesome, if you make sure that all your objects are
> serializable - this way you avoid locking database-Ressources. If your
> Client crashes and never commits your objects, the objects in your bean
> will be garbage-collected on timeout, so no ressources will be locked.
> Does this solve your problem?!
>
> cheers
> stf
>
> Paolo Bacco wrote:
> > Hi Stefan,
> > Application specs are:
> > 1- client is an applet.
> > 2- EjB acts as a Session Facade (stores client state) and has all
business
> > methods client needs.
> > 3- Applet require commit /rollback capabilities to SessionBean.
> > 4- EjB container supports only Ejb1.0 specs.
> >
> > Thanks.
> > Paolo
> >
> >
> > -- -- Original Message -- --
> > From: "Stefan Frank" <s.frank@(protected)>
> > To: <J2EEPATTERNS-INTEREST@(protected)>
> > Sent: Monday, November 24, 2003 4:12 PM
> > 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.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.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.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.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
