Hi Noel. I see you point. I believe the rfc1939 states the locking mechanism as *the* method to prevent messages from being modified or removed. The effects of locking are 2: - no other session (on the same james instance) can enter the transaction state before the first one enters the update state; because of that, no other session can modify or delete messages before the first session enters in the update state, i.e. deletes the messages. - two different mail clients accessing via pop3 the same mailbox will *never* get the same message.
About the last point, even thought the rfc1939 doesn't explicitly state it, it is a standard behavoir: we tested several mail servers and actually no one of them allows two clients to get the same message, because of the exclusive access lock. In our case, this is *very* critical: tho clients getting the same message would cause two different people to trigger the same administrative procedure. Cheers Marcello > Noel J. Bergman wrote > > Marcello, > > As I read RFC 1939 Section 4, we may not need to lock the > mailbox for exclusive use. The key phase is "as necessary to > prevent messages from being modified or removed before the > session enters the UPDATE state." > > At present, JAMES maintains the entire state of the mailbox > in memory during the transaction state. If another session > were to open and delete a message, we would need to ensure > that the deleted message was still available for the other > session(s) still in transaction state. > > In all cases, the maildrop should still permit new messages > to arrive, which would not be known to the current transaction state. > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
