PGStream synchronization

(missed CCing the list on my reply to Oliver)

> How about, instead of using raw monitor synchronization to provide
> mutual exclusion on access to the stream, we use a lock object (i.e.
> something similar to java.util.concurrent.locks.Lock, though we can't
> use exactly that class before 1.5 obviously), try to grab the lock
> before close, and behave differently depending on if we succeeded or not.
>
> So the close logic can look something like this:
>
>  if (lock.tryLock()) {
>    // we have exclusive access to the connection
>    // do a normal shutdown
>    try {
>      sendTerminate();
>      stream.close();
>    } finally {
>      lock.unlock();
>    }
>  } else {
>    // something is concurrently using the connection
>    // just abruptly close the connection
>    stream.close();
>  }
>
> In the concurrent case, we don't send Terminate, but we also don't risk
> sending it at the wrong point in the stream.
>
> This means that a concurrent Connection.close() while something is
> happening will result in an "unexpected client EOF" logged on the server
> side, but that's almost what you want in this case anyway .. concurrent
> close pretty much means "help, abort this!" ..
>
> -O
>

That's interesting. I think it's not quite in the spirit of the
protocol, but there may not be much more we can do, and it's certainly
a reasonable behavior. I'd like to spend some more time with the FEBE
spec tomorrow and then I'll submit a patch based on this approach.

Thanks,
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda(at)truviso(dot)com
www.truviso.com