Re: Avoiding Statement.cancel() races
От | Oliver Jowett |
---|---|
Тема | Re: Avoiding Statement.cancel() races |
Дата | |
Msg-id | 20031126022618.GD12218@opencloud.com обсуждение исходный текст |
Ответ на | Re: Avoiding Statement.cancel() races (Kris Jurka <books@ejurka.com>) |
Список | pgsql-jdbc |
On Fri, Nov 21, 2003 at 06:18:07AM -0500, Kris Jurka wrote: > > > On Fri, 21 Nov 2003, Oliver Jowett wrote: > > > However there's an obvious race condition here between starting query > > execution and cancelling the statement -- it's possible for > > stopWorkerThread() to run at just the wrong time and "cancel" the statement > > before it starts execution, having no effect and leaving the worker thread > > still running a query (at least as I understand cancel() .. that's how it's > > implemented in the postgresql driver anyway). > > What if calling cancel on a non running statement threw an SQLException? > Then your stopWorkerThread could retry the cancel. That might work. You'd need a separate SQLException subclass (or SQL state code) to distinguish "no statement running" from "cancel failed". I'm not sure if other applications would expect this behaviour, though. Also, I don't really like spinning on a retry -- you become quite dependent on the fairness of the JVMs threading/locking model. -O
В списке pgsql-jdbc по дате отправления: