culli (1) [Avatar] Offline
#1
In chapter 3, there is an example of a Stateless Session Bean with a PostConstruct that gets a connection from the DataSource, and PreDestroy where it closes the connection. In Glassfish at least this doesn't seem to be a good practice. Datasources in Glassfish are only created with an association to a connection pool, so if you hold on to the connection for the life of the session bean, that could be far too long, because you have taken that connection out of the pool for that whole time. The session bean might be pooled and not destroyed for a while. It's especially bad if Glassfish's connection pool leak detection feature is turned on. http://blogs.sun.com/kshitiz/entry/connection_leak_tracing

In general it seems like it would be better if the DataSource was injected, then the connections were allocated for only the context of a single business method. This would reduce the amount of time the connection is held from the pool, and increase throughput for the application as a whole, using less database connections, which can be a scarce resource.

What makes this all worse is that the BidManager example code crosses a page in the book, so if somebody misses the PostConstruct, they can create a connection leak. A colleague of mine did this in fact.

Just my thoughts. My experience with EJB 3 and Glassfish is not extensive, so that take that into account.

Regards,
Jim
reza_rahman (456) [Avatar] Offline
#2
Re: BidManager DataSource Comment
Jim,

You are correct. In a real production application, it isn't advisable to keep a connection open for the life-time of a session bean. We were just trying to create an example most developers could readily relate to. Of course, all of this is moot while using JPA instead of JDBC smilie.

Cheers,
Reza