• 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 ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

EJB connection pools vs. Individual Oracle logins

Posts: 20
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can anybody give me advice on using individual Oracle logins, rather then pooled connections with a common/shared account with EJB's? We are using WebLogic, and I have successfully set up and used connection pools. But, using this technique, Oracle connections are defined statically, and eveyone using a particular connection pool connects to Oracle with the same account (and privs).
I would rather set up our applications so that the database connection(s) are created at run time and connect to the actual Oracle account of the application user.
I realize that we might lose the performance benefits of pooling, but all of our applications prior to EJB have set up individual onnections at run time without creating performance problems.
Can this be done in WebLogic, and can anybody give me advice on how to do it? Or, is there a better idiom to follow in the EJB world?
Dave Segal
Ranch Hand
Posts: 52
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
While EJBs can be Local, they are really meant to run in a distributed world. As Connection objects cannot be passed from machine to machine, the Connection must be created in the same VM as the EJB, which is why the EJB container usually handles the Pooling.
Depending on how you've implemented your JDBC code, you may have an easy work around. If you've placed all the JDBC code in classes other than the EJB, you can just not use the EJBs. I usually create three sets of classes, one class for the data coming/going to/from the database, one class that holds all SQL and methods for creating the data beans via the SQL (usually only static methods that require a Connection as a parameter) and one set of classes that are the EJBs. The EJB remote/local interfaces usually miror the static SQL methods, without the need for a Connection object. The EJB gets a Connection from the pool and calls the static method in the DataAccessObject, returning the DataBean. If you implement this, you can cut out the EJBs, handle Connection creation yourself (from servlet, thick client) and just use the DAO/DataBeans.
Hope this helps and good luck.
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    Bookmark Topic Watch Topic
  • New Topic