William,
The call to close() is logical. The containers implementation of
java.sql.Connection.close() as you mentions returns it to the pool. However
if you are in tx the container will simply ignore this call and return
control not having closed the connection.
1) The advantage however is if you ever do change the tx property of the
component then this functionality may indeed change and return the
connection to the pool
2) It is however a good idea to also be calling close() in many cases at
every method call such that you do not have one connection for every SFSB
instance. I see alot of entity bean and SSFB code where they keep one
connection open during the whole beans lifecycle. If it is the root
component then the tx persists only for one method call, so there is no need
to maintain the same connection across method calls.
Im in favor of the below because its more portable in the fact it supports
the declarative tx settings of a container managed tx where the
functionality can change just from the declarative property change. I mean
yes in some cases the call to close() is ignored, but how expensive is a
return; :)
Dave Wolf
Internet Applications Division
Sybase
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of William Louth
> Sent: Tuesday, September 05, 2000 9:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Can I pass Connection object as a parameter to a Session
> Bean .
>
>
> JP,
>
> If the code lised below is executed within a transaction could you tell me
> the benefit of closing the connection at line 3. I am assuming we
> are still
> in the ejb server world. For a connection pooling mechanism to
> work requires
> that the connection is in a valid state to service other client requests
> (another transaction) when returned to the pool. This means that if a jdbc
> transaction has been 'started' on a connection then no other transaction
> other than the current transaction would be able to use it until the
> connection has received a 'commit' or 'rollback' call. This means that the
> calls at line 3 and 5 are not required and do not increase the scalability
> of your appserver.
>
> William Louth
> Inprise
> www.inprise.com/appserver
>
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Juan Pablo Lorandi
> Sent: Tuesday, September 05, 2000 12:12 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Can I pass Connection object as a parameter to a Session
> Bean .
>
>
> You don't need to pass the connection along, if you're using JDBC 2.0
> complaint drivers (as is the case with Oracle's thin
> named classes1xx.zip an above). In every method where you'll use the
> connection, create it (calling DataSource.create()),
> then use it, then close() it. In JDBC 2.0 every driver MUST implement a
> connection pool. To maximize the perfomance boost
> that this will give you, remember to hold on to the connection for the
> shortest amounts of time you can. For example,
> if within your method you connect to the db, perform so heavy
> calculations,
> then store some results back in, you should do as follows:
>
> (Pseudo Code)
> 1 - connect()
> 2 - executeStatement()
> 3 - close()
> 4 - Perform Calculations
> 5 - connect()
> 6 - executeStatement()
> 7 - close()
>
> Tough this, in contrast with not executing steps 3 and 5, may
> seem to lower
> the performance of your method (and in fact it does),
> it makes your app more scalable (by lowering the pressure on
> perhaps, IMHO,
> the most expensive resource of all: the database).
>
>
> My 2c,
>
> JP
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Balachandher S
> Sent: Saturday, September 02, 2000 10:40 PM
> To: [EMAIL PROTECTED]
> Subject: Can I pass Connection object as a parameter to a Session Bean.
>
>
> Dear all,
>
> Can I pass java.sql.Connection as a parameter to a session bean. I am
> trying with Oracle thin Driver. I am creating the java.sql.Connection
> object ( using Oracle Thin Driver ) after a login screen. If I am passing
> the same as a parameter to the session object, I am getting
> "ClassCastException".
>
> Any help in this regard will be useful to me. Is there any alternate
> mechanism by which I can reuse the same Connection object created
> during the
> Login.
>
> Thanks in advance.
>
> With regards
> sbchand
> _________________________________
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> ���������������������������������
> Srinivasan Balachandher
> Software Engineer
>
> MEDICOM Solutions (P) Ltd.
> 73-D, Electronics City
> Hosur Road
> Bangalore - 561 229
> INDIA
>
> Tel : 91-80-8520230
> Fax : 91-80-8520231
> URL : http://www.medicomsoft.com
> _________________________________
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> ���������������������������������
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
> ==================================================================
> =========
> To unsubscribe, send email to [EMAIL PROTECTED] and include
> in the body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
