The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

culli (1) [Avatar] Offline
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.

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.

reza_rahman (456) [Avatar] Offline
Re: BidManager DataSource Comment

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.