I'm using the same order as described on the commit mail.

Author: clebert.suconic@jboss.com
Date: 2009-11-23 21:53:23 -0500 (Mon, 23 Nov 2009)
New Revision: 8389


Added:
 trunk/src/main/org/hornetq/core/journal/IOAsyncTask.java
 trunk/src/main/org/hornetq/core/journal/impl/SyncIOCompletion.java
 trunk/src/main/org/hornetq/core/persistence/OperationContext.java
 trunk/src/main/org/hornetq/core/persistence/impl/journal/OperationContextImpl.java

^^^ I have tweaks a little bit the callbacks on the Journal, so I could have a proper abstraction to use on the OperationContext.

Removed:
 trunk/src/main/org/hornetq/core/remoting/impl/wireformat/ReplicationSyncContextMessage.java
 trunk/src/main/org/hornetq/core/replication/ReplicationContext.java
 trunk/src/main/org/hornetq/core/replication/impl/ReplicationContextImpl.java

^^^ I have removed that synchronization between the live and backup now, since the single OperationContext per session will do the proper synchronization and ordering now.

Modified:
 trunk/native/bin/libHornetQAIO64.so
 trunk/native/src/AIOException.h
 trunk/native/src/JNICallbackAdapter.cpp
 trunk/native/src/JNICallbackAdapter.h
 trunk/native/src/JNI_AsynchronousFileImpl.cpp
 trunk/native/src/Version.h
 trunk/src/main/org/hornetq/core/asyncio/impl/AsynchronousFileImpl.java

^^^ The native library needs support to the proper sequence on writes. Since we reuse the same callbacks now ordering on the callback is important for consistency and ordering. (not just ordering).

AsynchronousFileImpl is now playing with a priority queue making sure the callbacks are kept in sequence, according to the responses from the native layer. (JNI)

 trunk/src/main/org/hornetq/core/journal/Journal.java

- The Journal is exposing callbacks now. For each appendMethod now, there is also a version with a callback for completion. the callback used is always the OperationContextImpl, set by ThreadLocal on OperationContextImpl.


And an overal from the other changes.


- The OperationContextImpl is managed by the StorageManager (or eventually by the ReplicationManager).


- Each OperationContext will have its own executor (an OrderedExecutor). The OperationContext on the same executor used on the session. (Or else it wouldn't be possible to guarantee ordering).


The OperationContext is listening for both replication and storage events.


I know Tim suggested me to not listen for Storage while replicating. It would be easy to do that... I can just disable callbacks when replicated, but I don't know if I would suggest it.. Say, the backup failed and the live is now operational. I'm not sure I would be able to guarantee transactionality of the callbacks that are already in place.



I would say the key class for this work is OperationContextImpl.