My apologies folks, I misunderstood what my developer was telling me. Its completely my fault and it turns out that this race condition is not actually a problem. Since we never test the deleted resources, there isn't an issue with them. -Mark
-----Original Message----- From: byteio-wg-bounces@ogf.org [mailto:byteio-wg-bounces@ogf.org] On Behalf Of Mark Morgan Sent: Tuesday, July 24, 2007 9:59 AM Cc: byteio-wg@ggf.org Subject: Re: [BYTEIO-WG] ByteIO Interoperability Fiesta
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
-- byteio-wg mailing list byteio-wg@ogf.org http://www.ogf.org/mailman/listinfo/byteio-wg