> Trouble is, with JDBC as its currently implemented, the instant you
> Commit() or Rollback(), JDBC starts a new transaction automatically,
> since JDBC has no explicit Begin(). If that thread then goes
> quiescent for an arbitrary period of time (perhaps waiting for more
> messaging traffic, our apps are message driven factory floor
> middleware things), this transaction remains open. Our
> applications are characterized by bursts of frenetic activity
> followed by long idle periods, quite unpredictably.
I was under the impression that this was easily addressed by
delaying the onset of the next transaction after commit/rollback until
some actual statement activity began. (like a SELECT...)