From: | Joao Rui Leal <joao(dot)leal(at)ciengis(dot)com> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Deadlock while using getNotifications() and Statement.executeQuery() |
Date: | 2008-03-26 10:19:38 |
Message-ID: | 200803261019.39010.joao.leal@ciengis.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tore Halset | 2008-03-26 10:21:45 | Re: Non-ORM layers over JDBC |
Previous Message | Kris Jurka | 2008-03-25 20:11:52 | Re: Deadlock while using getNotifications() and Statement.executeQuery() |