You basically say:
db1: prepare to perform some operation;
db2: prepare to perform some operation;
On success of both prepare operations:
db1: commit;
db2: commit;
On failure of either prepare operation:
db1: rollback;
db2: rollback;
If there is a server/link failure between the two commits, you still get out of sync.
In the JAMES case, the db's are the repository and the remote server/local mailbox/etc.
As far as I can see, it is actually not possible to eliminate this window of error. The only thing that can be done is to make it as miniscule as possible. I would say that has been achieved.
There is possibly one improvement that could be investigated. It may be possible to track the progress of a mail through the processor, so that when it resumes after a crash, it resumes at the same point - essentially, this would mean saving state after every mailet. I am not sure that this is really something that belong in JAMES' feature set, however. Applications requiring this feature are probably a small minority and nothing prevents them from implementing it themselves. (It would be quite simple.) For the rest of the JAMES user base, the performance hit incurred by saving state between every mailet would probably be unwelcome.
ADK
Noel J. Bergman wrote:
This is a transaction issue. But there is no mechanism within SMTP for a two-phase commit. There is always some chance that between storing the message and advising the client that the system could crash. For that matter, after sending an acknowledgment to the client, there is some chance that the packet could be lost. This effects receipt and relaying by James.Internally, mail is queued between the handler and the spool manager, and then within the spool manager for each transition between processors. Not for each mailet. What you want is a transaction, so that the process of your storing the mailet in the database, and the message being removed from the spool appears to be atomic. But there is no two-phase commit within the spooling mechanism. If your mailet puts the message in a database, as LocalDelivery can, then your mailet should set the state to GHOST, and the message will be removed from the spool, so that the only copy will be the one you saved. As I said, there is a small window between storing the message in the database, and when it is cancelled from the spool. Very unlikely, but possible. --- Noel -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
