views:

165

answers:

3

I have a j2ee webapp that's being used internally by ~20-30 people.

There is no chance of significant growth in the number of users.

From what I understood there's a trade-off between opening a new DB connection for each request made to the webapp (expensive, but doesn't block other users when the DB is in use), to using the singleton pattern (doesn't open new connections but only allows one user at a time).

I thought that since I know that only 30 users will ever use my webapp at the same time, maybe the simplest and best solution would be to store the connection as a session attribute, thus reducing to a minimum the amount of openings made, while still allocating one connection per user. What do you think?

A: 

No. Don't do that. It's perfectly ok to reconnect to the database every time you need to. Any database management system will do their own connection pool caching I think.

If you want to try to keep open connections you'll make it incredible hard for yourself to manage this in a secure, bug-free, safe etc way.

Makach
Well, I now tried keeping the connection alive.the JSP's I have make a lot of small ajax requests, in which I definitely saw an improvement in performance. Probably because the query+data sent in those ajax requests are rather smal, so establishing the connection caused most of the overhead.Also, I understand completely that this method "looks" wrong, and like all programmers I also have an OCD against ugly code :) But when thinking it through, I can't see any way in which it will cause any security or bugs... can you give me an example?
noam
+1  A: 

I think you're getting into premature optimization especially given the scale of the application. Opening a new connection is not that expensive and like Makach says, most modern RDBMSs handle connection pooling and will hold connections open for subsequent requests. You'd be trying to write better code than the compiler, so to speak.

Nick Swarr
+2  A: 

From what I understood there's a trade-off between opening a new DB connection for each request made to the webapp

That is what connection pools are for. If you use a connection pool in your application, the pool once initialized, is in charge of providing connections for use in the application as and when needed. In a properly tuned connection pool, there are going to be enough connections created on reserve that can be provided to the application, mitigating the need to create and open a connection only when the application requests for it.

I thought that since I know that only 30 users will ever use my webapp at the same time, maybe the simplest and best solution would be to store the connection as a session attribute

Per-user connections are not a good idea, primarily when a web application is concerned. In a web application, it is perfectly possible for users to initiate multiple requests to the server (think multi-tabbed browsing). In such a case, the use of a single connection per user will result in weird application behavior, unless you synchronize access to the connection.

One must also consider the side-effect of putting transient attributes into the session - Connection objects are not serializable and hence must be marked transient. If the session is deserialized at some point, one has to account for the fact that the Connection object will not be available, and must be re-initialized.

Vineet Reynolds