Re: Deadlock while using getNotifications() and Statement.executeQuery()

On Tuesday 25 March 2008, Kris Jurka wrote:
> On Tue, 25 Mar 2008, Joao Rui Leal wrote:
> > I did a workaround/hack to fix the problem, but there should be some
> > better way to fix this. I had to make sure that the locking order in
> > getNotifications() is same as in executeQuery(), but that meant exposing
> > the QueryExecutor in the ProtocolConnection (the QueryExecutorImpl is
> > saved as private variable inside ProtocolConnectionImpl). So I had to
> > make the following changes (it's not pretty, I know...):
>
> I don't see why you need access to the Impl version.  Isn't "synchronized
> (getQueryExecutor())" around AbstractJdbc2Connection's
> protoConnection.getNotifications() sufficient?

I haven't tested it yet but you seem to be right. I didn't know there was such
a method (1st time going through the API). I guess if it returns the
org.postgresql.core.v3.QueryExecutorImpl object then the locking will be in
the same order as in executeQuery().

>
> Still that's not a real clean/understandable design.  Perhaps instead
> processNotifies() should be added to the public QueryExecutor interface
> and then AbstractJdbc2Connection can call processNotifies itself so that
> fetching notifications from protoConnection doesn't require any
> interaction with the QueryExecutor.

I agree.

Joao Leal

>
> Kris Jurka