> > Well, the service exists to provide a middleware layer between a client >and > > a database, so that's pretty much all that will be going on during a > > session. Our Oracle DBA doesn't like the pooled connection idea because >it > > makes troubleshooting harder for him. He'd rather that unique clients >were > > mapped to specific database logins so when user X calls to say "my session > > crashed," he doesn't have to dig through log files to find out which > > session that was. > >maybe you should make mapping from username to session ID in the logs >easier. > >IMO any admin task on a server is a valid use case, a use case your code >should support.
Yup, I'd prefer to write a connection-pooled service and provide good diagnostic tools, but our DBA would rather keep things in his domain and not be dependent on an interface I provide. He is, after all, the DBA, and I'm just the clueless kid writing his first real Java app. Frankly, I wouldn't trust me either. ;) > > Anyway, as I discovered five minutes later, a Connection > > object is automatically closed when it is garbage collected, and that > > should suffice. We don't anticipate a large number of simultaneous users. > >You are relying on garbage collection being approximately deterministic >then, and not having objects hang around for 30 minutes or more Only in the case where the communications go bonkers. In the normal case, a client would send the quit command to end a session, at which point I'd explicitly close the Connection. An open Connection would only get left around when, for instance, the client failed to send the quit command and the session timed out on its own. Honestly, I didn't realize garbage collection could take that long. I'll look into ensuring that gets cleaned up more reliably. Andrew
