as by subject, I've a question for you about passing a Connection instance as parameter to an EJB method exposed via local interface.
As far as I know, passing a Connection is teorically impossible with remote interfaces, where serialization mechanism is involved, and being a Connection not serializable, this should raise a NotSerializable exception. Of course, unless EJB container recognizes that EJBs are co-located and avoids actual serialization, simply passing parameters by value. With local interfaces, the whole thing works, but I'm still in doubt if using a connection is a good practice or not. I've read several articles (and several posts here at Java Ranch) where it was stated that generally speaking no, that's not kosher; but in most cases there were scenarios
where someone tried to reuse the same connection object to handle manually transaction, bypassing container capabilities. In those cases, it's quite clear that there's an attempt to break EJB design; but let's suppose we have a scenario where an EJB facade method (for example) needs to call several local EJBs. Would it be worth, to save the number of actually got-and-closed connections from the pool, pass the same connection, since apparently there are no problems ? Or the problem of saving the number of connections is, simply, a false problem just because time spent acquiring connections from a pool is practically insignificant ?