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?
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.
Kris Jurka
