On Oct 31, 2007 9:49 AM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > 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. > > I don't tell that a session should have a single transaction. It is > possible to manage multiple transactions in a session. My question was > how you manage transactions if you don't have a session at all.
the problem is that session is used in two different senses: database session and a session of a (session-oriented) protocol if you're using a transactional datastore then yes, you'll need a datastore session to execute transactions but there is no necessity for this to equal the MailboxAPI session > >> 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 > > Not sure I understand: so you tell we need a "data store session" that > is something different from the IMAP session. Well, if so, I agree with it. the question is whether MailboxAPI session should equal data store session > Maybe the problem is that I don't know what the MailboxManager > responsibility and API users are/will be so I don't know what layer of > the architecture will be involved by this "API Design" thread. i agree that this is the major problem: we need to understand the use cases better - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
