File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes EJB and other Java EE Technologies and the fly likes Passing java.sql.Connection to finder methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Passing java.sql.Connection to finder methods" Watch "Passing java.sql.Connection to finder methods" New topic
Author

Passing java.sql.Connection to finder methods

Rusty Enisin
Ranch Hand

Joined: May 26, 2005
Posts: 107
I am fairly new to EJBs. I am working on an existing system that has a bunch of BMPs.

Here is the code from the home interface (I have changed the names to protect the "innocent"):



When I saw this, I did not really understand why it was done this way. I wondering if there is someone here that may help me understand this. Why would you pass the java.sql.Connection to the finder method?

I asked around and was told that they do this because getting connections is one of the most resource intensive things you can do. OK. But use a pool, right? No. Those are too resource intensive, too, they say. So they get a connection themselves and then pass it to the beans they use. The theory is that doing it this way is faster.

Does this make any sense?

I sounds like it might be faster at first glance. But it also seems odd. Something inside of me pulls back and wants to die. But I don't know enough about this to trust myself gut instinct on it. There must be something better than this.

When I think about it, pools are better and faster than creating a new connection. No problem there. But is managing your own connections and passing them around better than pooling? Getting a connection from a pool would have a little overhead. But would it be enough to worry about so much so that you do this to your beans?

Is there a better design pattern for this? Or is this a really good way to do it?

As a side note, what do you think about the naming scheme (putting BMP or CMP at the end of the bean name)?


The squeaky wheel gets the grease. Well, that or replaced...
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Rusty,

Please read this thread, it is probably not the answer you'd like to hear but might give you some clues why some people believe it is faster this way:
http://www.coderanch.com/t/316281/EJB-JEE/java/Transaction-EJB-session-bean
Regards.


I think, therefore I exist -- Rene Descartes
Rusty Enisin
Ranch Hand

Joined: May 26, 2005
Posts: 107
So the result looks like this: The only reason to pass the connection should be something along the lines of managing your transactions from a single place so you can rollback several methods calls together. You could do it to reduce the number of new connections, but you should be getting that from a pool wither you are getting the connection and passing it or getting the connection within the BMP.

Either way, by passing the connection, it is breaking a big design pattern by putting the data layer in the business logic. It is not the end of the world to break a design pattern. But when you break one this big, it should send up a red flag for you to look really hard at finding another way if you can. Or at least find a new way to solve what the design pattern does.

If we switched from one database to another, we would have a hard time. Of course, a way around this is to use a properies file or a config file of some sort to define this kind of stuff in a central place. Many use some sort of a lookup factory that would return the connection of type java.sql.Connection that you want. That would seem works well and keeps the data layer out of the business and lets you use a single connection if you want.

Anyway. It is interesting. I learned a lot.
Roger Chung-Wee
Ranch Hand

Joined: Sep 29, 2002
Posts: 1683
When I saw this, I did not really understand why it was done this way. I wondering if there is someone here that may help me understand this. Why would you pass the java.sql.Connection to the finder method?

I asked around and was told that they do this because getting connections is one of the most resource intensive things you can do. OK. But use a pool, right? No. Those are too resource intensive, too, they say.

They are wrong. The main cost is in creating the pool and establishing the DB connections on server startup. Obtaining method-ready connections is cheap. The same principle applies to other pools, eg stateless session beans, entity beans, message-driven beans.


SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Valentin Tanase
Ranch Hand

Joined: Feb 17, 2005
Posts: 704
Hi Rusty,

You are very right it is not the end of the world to break a design pattern (I�m happy to see people are still thinking this way :-)) and one could debate a lot upon this subject. However in this particular case your doubts are very entitle because in my opinion it�s hard to justify the use of a connections in public methods. I �broke� the original design pattern true, but what I was thinking actually was about having private methods that takes the connection as an input parameter. This way the client calls any business method following the usual approach; the bean knows how to request a connection from the DAO, which in turn knows how to get the connection from the pool. From there on the initial method can pass down the stream that connection. But if a public business method takes a connection as an input parameter, then one needs to ask the obvious question: �and how suppose to get the client the connection in the first place anyway?� This goes back to the idea that the client can access the DAO directly, bypassing the business layer and here I have to agree with you, this is a little bit too big even for me :-)
Regards.
 
Consider Paul's rocket mass heater.
 
subject: Passing java.sql.Connection to finder methods