> 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.
>
OK, now I got your problem. For this one I can't imagine other solution
than fixing it on the DB side :-)
Just as a side note: if you use a connection pool which is under your
control, it still could prove useful to sort of "refresh" the
connections from time to time by dropping connections which are in
service for longer than a maximum time to live (say a few hours).
This way you avoid possible problems with resource leakage which
occasionally can happen.
> in this particular case, the lock is to simply indicate there is an active
> 'subscriber' to a messaging 'subject', if the app has exited any which ways,
> by definition that 'subscriber' is no longer active, so yes, we want the
> lock to go away.
>
Now this looks to me more like a "registry" than a lock.
In any case, it could be replaced by some leasing scheme, where you
place a record which expires after a specified amount of time, and the
active process has to refresh it from time to time to keep it active.
I'm just that against DB locks, the hit my back a few times...
Cheers,
Csaba.
