> 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!" ..
I read through the FEBE spec (props to the documenters, by the way--it
was very clear and concise), and discussed this with a colleague, and
he suggested a hybird approach based on what you are doing here and
what I suggested initially.
Essentially, the 'if' part of your pseudocode would be the same, but
in the 'else', instead of just closing the connection, fall back to my
original approach (issue CancelRequest / CopyFail and then Terminate).
I think this is somewhat cleaner but only incurs the expense of a
CancelRequest if you really are doing something else on that
connection at that moment.
--
Maciek Sakrejda | Software Engineer | Truviso
(650) 242-3500 Main
(650) 242-3501 F
msakrejda@truviso.com
www.truviso.com
