Connect to Oracle from J2EE. Use Oracle connection pooling or Java

DBAs,

The argument is - from a Java Application Server (using J2EE) should you:-

(a) Let J2EE manage the database connection pooling (and therefore
connect to a single Oracle USER) or

(b) Let Oracle 8i manage the connection pooling (9i soon), with every
user connecting to a dedicated NAMED Oracle USER and therefore tighten security

I think the Java Development Architect is suffering from "not invented in Java" syndrome here. He's insisting that the team NEED to connect to Oracle through a single USERID and therefore handle all the security within the Java Application Server and the custom built application itself. His argument INCLUDES the need to pool (ie. multiplex) database connections in the Java Application Server, and as Java is my PERSONAL weak point he's playing that card particularly strongly.

To give some background. Platform SUN V880 with 4 CPUs and 4 GB memory. Users currently absolute maximum of 50, with growth to 200 maximum in 3 years. Typically you'll have about 10-20 users online at any time - but working against very large data sets. ie. Typical Data Warehouse profile - not OLTP where these connection pooling type solutions are a concern.

If anything major DBA concerns on the system are security since the data has a very high value, and (currently internal only) if we host services for external clients, they MUST be guaranteed both secure access and complete separation for other client data.

Second greatest concern is (unrelated) - we have a potential terabyte database within a year.

My gut feeling is (b) every time for the following reasons:-

(1) I understand Oracle 9i includes "Virtual Private Databases" which
will be difficult or impossible under option (a)
(2) Security is a nonsense with every user coming in via a single
connection
(3) The DBA can't identify individual users so can't monitor them,
audit them or kill them if needed (Auditing may be vital in this system !)
(4) Option (a) leaves a single connection point and therefore single
point of security failure (does option (b) leave several?)
(5) Option (a) means the password of the single point of entry must be
recorded somewhere accessible from within Java (insecure)
(6) Option (a) rules out all Oracle built in object (eg. table) level
security, and means the application must re-invent the security model
(7) Need I go on?

Is there anyone out there who feels differently? Is there a compelling reason for (a) ? Are there any alternatives ?

It seems to me the Java Architect thinks I'm being paranoid about security (justifiably so) and protective of my own domain (about as far away from the truth as it's possible to be).

Many Thanks in advance,

John Ryan
(You learn something new every day - sometimes every minute).
Received on Wed Jun 26 2002 - 04:35:06 CDT