[BYTEIO-WG] ByteIO Interoperability Fiesta

[Mark Morgan]

Correct me if I'm wrong Michel, but isn't it the case that there are
test cases in the interop fest. which require you to delete a resource
and then send another message to that resource to verify that it was
deleted (by virtue of the fact that the container issues a fault)?  If
so, then the race condition in question affects the clients of the
interop. fest.  It isn't fair to say that an implementation MUST
guarantee monitor semantics on their resources and without a result
value from the service indicating success of the delete operation, there
is no way to guarantee the order of operations on the service (even
though by virtue of the fact that the two messages in question are
coming from the same client, and the nature of TCP/IP I agree that the
messages WILL in fact arrive in the correct order, I still don't believe
that its correct to assume that a service chooses to handle two
asynchronous messages in the same order that they arrived in unless the
client guarantees it by blocking on results).

-Mark

On Tue, 2007-07-24 at 14:45 +0100, Michel Drescher wrote:
> Hi,
> 
> Mark Morgan wrote:
> > The race condition is that a multi-threaded server may not finish destroying
> > a resource before the client sends the next request to the resource.  In our
> > code, if our client has:
> > 	send_op()
> > 	destroy()
> > 	send_op()
> > The second send_op() succeeds (whereas it should fail) unless we pause
> > between the destroy and the send_op.  The reason for this (I believe) is
> > that destroy in Genesis II is slightly heavy-weight in that it needs to
> > (potentially) send out notifications and clean up WS-Naming resolvers.
> 
> But if I understand that right, the race condition is in your code (or
> hosting environment) rather in the messaging itself?
> 
> Cheers,
> Michel
> 
>