Problems I see with a) is
1. when a process crashes that has a lock, how does that message get
unlocked and
2. how do other processes get notified when a message is in the spool?
(there's no call back mechanism). this means instead of a wait() or some
callback, we have to check rather frequently to see whether any messages are
in a spool. it does solve multithreading though.
I like b). Certainly performance might suffer, but if you're running
multiple instances, that's to be expected (like why dual processor isn't
twice as fast as a single). Sounds like an interesting concept though. I'm
not sure how you'd determine which was the central authority for the locking
or how callbacks would work (for spools to get notified of unlocks).
Also I wanted to note again that spool != locking. There might be issues
with POP3 mailboxes, but certainly with IMAP where you need the repository
to be threadsafe (have locking) even though it's not a spool.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Harmeet" <[EMAIL PROTECTED]>
To: "james-user" <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 4:01 AM
Subject: Proposal to fix 'Can 2 instances of JAMES share the same database'
> I think what would be best is to have locking not tied to a process. This
> would allow scalability.
>
> This could be done in several ways.
> a) For File System based repositories, it would be a matter of changing
the
> extension of message a spool thread is working on and renaming to orig if
> spool processing fails.
>
> for example
> File spoolFile = ....
> boolean reset = false;
> try {
> spoolFile.renameTo(<spooled file with status in-process>)
> catch ( Throwable t) {
> reset = true;
> throw t;
> } finally {
> if ( reset )
> <spooled file with status in-process>.renameTo(spoolFile);
> }
> The same thing could be done in db, by setting a 'in-process' flag for
spool
> message.
> The spool threads will pick and process messages that are not being
> processed.
>
> Another way could be to
> b) have a lock-server process that controls object locking and lifetime.
> Basically lock facility could be leased out for sometime, and renewed or
> staus success/failed returned. Lock Sever solution is nice and general but
> it may be an overkill. It may however be a good Avalon Block to have. It
is
> a nice Server Piece to have when you need it.
>
> This would allow multiple processes to process the spool messages.
> This would not be as fast as the current single process based locking, but
I
> think the spool processing does not need to be fast, but it does need to
be
> scalable and correct (i.e one email for one message)
> This can be very scalable, one could have multiple instances of James
behind
> a load-balancer/virtual address, to service high volume.
>
> Here is a proposal for your vote.
> Let us implement method (a) to allow multiple processes of James to
process
> same spoll db.
>
> If you like the idea, I can do the File Repository part of it over the
> weekend.
>
> What do you think ? Does this make sense ?
> Harmeet
>
>
>
> ---------------------------------------------------------------------
> 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]
