Jessica,
My reading of the JDBC spec would indicate that this is a statement
level property (aka query level) since the method to enable this is on
the Statement object and is named setQueryTimeout(). There is nothing I
can find that would indicate that this would apply to the transaction in
my reading of the jdbc spec.
thanks,
--Barry
Jessica Perry Hekman wrote:
> On Mon, 1 Apr 2002, Bruce Momjian wrote:
>
>
>>I don't know which people want, and maybe this is why we need both GUC
>>and BEGIN WORK timeouts. I don't remember this distinction in previous
>>discussions but it may be significant. Of course, the GUC could behave
>>at a transaction level as well. It will be tricky to manage multiple
>>alarms in a single process, but it can be done by creating an alarm
>>queue.
>
>
> I think we should do just BEGIN WORK (transaction-level) timeouts; that is
> all that the JDBC spec asks for. Does that sound good to people?
>
> So the work that would need to be done is asking the driver to request the
> timeout via "BEGIN WORK TIMEOUT 5"; getting the backend to parse that
> request and set the alarm on each query in that transaction; getting the
> backend to send a cancel request if the alarm goes off. I am right now in
> the process of finding the place where BEGIN-level queries are parsed. Any
> pointers to the right files to read would be appreciated.
>
> j
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
>
