• 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

Using DataSource in EJB

 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have an EJB question that I wanted to raise here.
I am using DataSource objects in the EJB application and using the app server provided connection pooling capabilities. The application server is iPlanet 6.5 and the database is DB2.
We also have a customer connection pooler that was written here for web applications that were not using EJBs. Now I want to ask that what horrible things can happen if we don't use the app server connection pooling and start using the customer pooler that was developed here in our EJBs. Is it a requirement in the EJB specs that we only can use DataSource objects in the EJBs that are registered with the Application Server. Would the transaction management be effected since the DataSource is not registered with the App Server?
Any input would be appreciated.
- Razi
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Needless to say the vendor support classes will be more robust and failproof than any homegrown versions. Add to that the app server specific features the vendor classes can make use of that your version may not. Put succinctly, it would be prudent to go with the vendor packages unless you can certify your custom classes are not only 100% compliant with DataSource implementation specs, but also perform better.
 
Razi Abbas
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the input. I agree that its always a better idea to go along with the vendor provided implementation for the reasons that you mentioned. But I am just curious to know if there is something in the EJB specs that requires us to register DataSources with the app server. Can we use old-fashined way of looking up connections using DriverManager and not use DataSource as the connection factory. Theoratically if the custom pooling mechanism is very robust, then we can use it in the EJBs without serious consequences. I am particularly interested in finding out that would the container transaction handling be effected if we are not using DataSources registered with the app server.
 
author
Posts: 3892
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, there is a VERY good reason to use the container-provided connections. Anything that is NOT taken from the container-provided datasources will NOT be enlisted in the EJB transaction. So, if you plan on using EJB transactions (either container-managed or bean-managed) you must use the container-provided Data Sources.
Kyle
 
Razi Abbas
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks for the answer. This defintely rules out using the custom pooler in our application.
 
Ranch Hand
Posts: 321
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Abbas,
you can still use the custom connection pool, but you hve to do away with using EJB.Instead you can use JDO's .For encapsulating the workflow logic you can hve a plain bean which will use your custom connection pool to talk to the JDO layer which is mapped to the underlying data-store using a OR/MAPPING tool..
but its a lot of work on the developers part.
Rishi Singh
SCJP,SCWCD
 
reply
    Bookmark Topic Watch Topic
  • New Topic