• Post Reply Bookmark Topic Watch Topic
  • New Topic

Passing connection object as arguement in method calls?

 
kapil Gupta
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
We are using Stateless Session Bean to get/set data from/to database. The exposed APIs internally call a number of private methods to update the database or in creating the returned dataobject. In some cases we are even calling local methods of other beans to get/set data. Is it a good idea to get the connection object from datasource in the exposed API and pass it as arguement to method calls?
Thanks & Regards,
Kapil
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We had a simlar debate on this subject a while ago.
http://www.coderanch.com/t/316281/EJB-JEE/java/Transaction-EJB-session-bean
My preference is to obtain (from a DataSource), use and close the Connection in the same method (using a local Connection variable). By doing it this way it is hard to go wrong, either from a production or maintenance point of view. Whilst I acknowledge that there is going to be a penalty in obtaining a Connection from the pool, as the container may do things such as test the database connection before releasing the Connection, I believe that clarity of code and allowing the container to manage the pool should override issues such as perceived performance gains from passing a Connection from method to method.
 
Rajesh K. Ilango
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kapil,
Your would need the connection for Transaction management alone. right!!!
Since you are using Session bean you can use the User Transactions for managing your transactions or you can set the transaction attributes at method level for all the methods in Session bean.
Passing Connection as function attribute is not a good idea.

regards,
Rajesh Kumar Ilango
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Passing Connection as function attribute is not a good idea.

Why not Rajesh?
 
Osuwari Inu
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Good question. My instinctive response was: "Ewww NO!". But to be honest, I cannot really think of a reason why it should not be done. (Passing the connection as a variable from a publicly accessible method to private 'handling' methods doesn't sound too bad. I realised I do it myself in the following scenario:

.public DataObject gimmeA()
.____throws SQLException
.{
.____Connection c = null;
.____PreparedStatement pstmt = null;
.____ResultSet rst = null;
.____String query = "some query defined somewhere in a central location.";
.____try {
.________c = acquireConnection();
.________pstmt = c.prepareStatement( query );
.________rst = pstmt.executeQuery();
.________if ( rst.next() ) {
._____________return readDataObject( rst );
.________} else {
._____________return null;
.________}
.____finally {
.________closeDBStuff( c, pstmt, rst );
.____}
.}

The closeDBStuff method attempts to close any given non null pointers. I use this method to avoid tedious code duplication of trying to close something and reporting upon error.

The readDataObject type methods allow for some code reuse if one has to load different sets of data objects of the same type. (I.e. all users of a group, or users of a group including all the users in all the subgroups).

Hope I didn't duplicate part of a previous discussion

(Sheesh indentation is a bitch )
[ July 07, 2005: Message edited by: Osuwari Inu ]
 
kapil Gupta
Ranch Hand
Posts: 89
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One scenario where passing connection to local methods wont work will be:-
If a servlet calls a local method of session bean then there is no point of creating connection object in servlet. So the API wont be generic enough to be called from other session bean or a servlet that may reside in same JVM of the application server. Am I right?
Kapil
 
Roger Chung-Wee
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no difficulty in a servlet calling any bean method and passing in a Connection (assuming, of course, that the signature declares a parameter of Connection type). However, this would not usually be good practice.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Kapil,


One scenario where passing connection to local methods wont work will be:-
If a servlet calls a local method of session bean then there is no point of creating connection object in servlet. So the API wont be generic enough to be called from other session bean or a servlet that may reside in same JVM of the application server. Am I right?

Well you�re right here, this will never be a good practice. But the real idea was that you�ll implement the entire logic in your session fa�ade and therefore you�ll call a public method from your servlet which doesn�t take the connection as an input parameter. This public method could be broken down in several more private methods that could share the same connection; something similar with Osuwari�s example above. I hope you agree with me that this is a very feasible scenario and many times one could implement private methods in a SLSB in order to share common behavior with other public methods. If for example you have a public method A() that calls three private methods X(), Y(), Z() then it could be very efficient to pass the connection along from A() down to X(), Y() and Z().
Generally speaking people are very reserved to choose a specific design strategy, simply because some j2EE design patterns or Sun best practices will forbid it. Well let me tell you one more thing: we are talking here about a technology that has been revisited twice already and it will be refactored for the third time soon. In my opinion I won�t take anything for granted only because Sun says so. They already proved me to be so inconsistent and contradictory with their own ideas that it will take probably another 100 years to make me trust them blandly. Till then everyone is free to use his own judgment ...
Regards.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!