Re: Hibernate / other ORM and pg_advisory_lock

From: Andrew <archa(at)pacific(dot)net(dot)au>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Hibernate / other ORM and pg_advisory_lock
Date: 2008-04-07 06:48:29
Message-ID: 47F9C3BD.6050205@pacific.net.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

I'm overlooking the cancellation of the query on a separate thread with
the JDBC cancel() method. Though that method always seems to have
issues associated with it across various drivers. But still, for what
you are talking about, I think a long running transaction is still going
to be your biggest problem rather than a long running query.
> I can understand how you would release the advisory lock by running
> another SQL statement in another thread to do so, but I do not know if
> that is of much use to you. As far as I know you can't tell a running
> JDBC query to abort or cancel a running query. Such calls, either at
> the JDBC level or at the JPA level are blocking calls for the client
> and about the only influence you have on it is by setting the query
> time out before executing (which has its own set of issues in the
> postgresql driver
> (http://www.nabble.com/Implementing-setQueryTimeout()-td15537669.html))
> Of course the UI client can always manage calls to its access layer
> via another thread and kill that thread if the end user becomes
> impatient and not want to wait. But from my understanding, that query
> with the back end database process will still be running and the DB
> connection will still be in use, including all of the associated locks
> and DB threads. So a subsequent attempt on a long running query will
> also block. However it the queries are all short running but are part
> of a long running transaction, then you can rollback the transaction
> at any point, but any other calls in a separate transaction dependent
> on those locks held by the running transaction will result in the
> aforementioned blocked call. You have to remember that at the ORM
> level (which is just a wrapper to the JDBC), or at the JDBC level, you
> do not have fine grain control of what is happening in the back end,
> and in my mind you should be looking at what JDBC provides, not what
> the underlying DB may be able to provide, and in using pg advisory
> locks, you are mixing the two.
Cheers,

Andy

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Craig Ringer 2008-04-07 07:53:54 Re: Hibernate / other ORM and pg_advisory_lock
Previous Message Craig Ringer 2008-04-07 06:30:06 Re: Hibernate / other ORM and pg_advisory_lock