• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Passing java.sql.Connection to finder methods

 
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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)?
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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:
https://coderanch.com/t/316281/EJB-JEE/java/Transaction-EJB-session-bean
Regards.
 
Rusty Enisin
Ranch Hand
Posts: 107
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1683
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Valentin Tanase
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic