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