On Oct 30, 2007 2:16 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > for example, in the current API to perform an operation, it's > > necessary to create a session. however, sessions are heavyweight: > > performing extensive pre-emptive caching. this is fine when dealing > > with heavyweight session oriented front ends but not so good for > > lightweight front ends. IMAP is session oriented but this design > > decision in the MailboxAPI results in poor performance for any calls > > that do not run against the selected session. > > How do you handle transactions if you don't use a Session or a similar > concept?
there are various ways that transactions can be handled and a session can mean many different things. equating transaction with session is an error. IMAP opens a mailbox session and may well leave it open for 30 minutes or more. if a transaction were associated with a session then this would probably time out but (more importantly) it would no deliver the correct semantics. commands are atomic and many can be issues within a single session. the results of each command should be immediately visible to all other users. > IMHO one of the missing things in JAMES Server is transaction support. > When a processor run a mail through a single step (a mailet) it should > either completely fail or completely succeed. > > How do you plan to support a simple LIST, RETR, DELE scenario without a > session? The list gives you identifier that are valid only in that > session, the following retr and the dele must use the same numbers. > > Are you simply saying that MailboxManager should be stateless and the > session should be managed on top of this? a stateless Mailbox shared by many users would prevent confusion about what a mailbox session really is explicit data store session and transaction management would at least then be clear - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
