Mark Morgan wrote:
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)?
I would not know which one that would be. All but one test cases test ByteIO operations, whether Random ByteIO or Streamable ByteIO. The only external operation that is tested is the GetResourceProperty operation. To my knowledge of the document all test cases MUST follow the pattern: 1. Create resource (through the factory) 2. Execute the test case 3. Delete resource (through the factory) So if you would want to test, say "Read(I)" and "Read (II)" in one test client invocation, then the overall sequence would look like this: 1. Create resource "a" (through the factory) 2. Execute test case "read (I)" on resource "a" 3. Delete resource "a" (through the factory) 4. Create resource "b" (through the factory) 2. Execute test case "read (I)" on resource "b" 3. Delete resource "b" (through the factory) The idea is that, whenever you execute whichever test case, you always can expect a resource with a particular layout/contents on the back end. THe fact that the write, append and truncAppend test cases invoke the read operation to test whether the file contents has changed as expected is an implementation detail as those operation invocations all fall under the "Execute the test case" sequence.
If so, then the race condition in question affects the clients of the interop. fest.
If it were so then yes, you would have a point. But, as to my knowledge, the interop testing spec never meant to use one resource for all tests. They were all meant to be executed on their own individual resources.
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).
The design of the deleteResource operation was never meant for the server side to guarantee anything. It was designed so that the client tells the server "guy, I'm done with this resource, ditch it, I am interested no more in this resource". The implicit obligation on the client thus is to never ever consider that resource to be extant anymore. The interop testing spec ensures that by stating that, for each test case described, the client MUST invoke the factory's "createResource" operation first, then, following the test case description, invoke some RandomByteIO or StreamableByteIO operations on that EPR, and then destroy that resource (invalidating the current EPR) afterwards as some means of cleanup. For example, in our implementation, our RandomByteIO resources do have a lifetime of one minute. After that, the resources expire automatically and are cleaned up. So in essence I do not need the deleteResource operation at all. It is there to let service implementations know when they can clean up an interop resource because it is no longer needed anymore. In our implementation, to avoid race conditions, we do two things: - Use a Java mutex lock to synchronize key parts of our code - When we receive the command to delete a resource, whether through the interop factory operation, expired lifetime infrastructure, or other means, the first thing we do is to disconnect the resource from any messaging connector. In effect our messaging connector then considers the resource nonexistant and sends back a fault. The fact that this fault is not the ResourceUnknownFault is our problem - a problem that I expect any WS hosting environment has. I know this for a fact for JAX-WS and Axis, unless you hack the hosting environment itself. - The code part that disconnects the resource from and messaging connector is guarded by the same Java synchronize() lock as any other vital part of our implementation. Cheers, Michel