I started writing something, but now that I think about this, locking and
spool really aren't related. A standard mail repository needs locking... if
you have multiple threads potentially modifying messages in a repository,
you need locking, regardless of whether it's being used as a spool.
I like the pluggable locking mechanisms idea (if someone else has the
time/interest to write such stuff), so what about having some conf setting
for any mail or spool repository to use an alternate locking mechanism
rather than the simple in-memory one?
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Darrell DeBoer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 08, 2001 10:10 AM
Subject: Re: Proposal to fix 'Can 2 instances of JAMES share the same
database'
> On Wed, 8 Aug 2001 18:01, Harmeet wrote:
> > I think what would be best is to have locking not tied to a process.
This
> > would allow scalability.
>
> Agreed - the locking mechanism should probably be implemented
independently
> of java thread locking.
>
> >
> > 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.
>
> Just thinking...
> Would it be possible/useful to separate the SpoolRepository implementation
> from the MailRepository; so that a SpoolRepository delegates calls to a
> MailRepository contained within? The SpoolRepository implementation would
> handle locking/respooling of message ids, but not the physical storage of
the
> mail.
>
> Possible benefits:
> a) keep the MailRepository cleaner, since it wouldn't have to handle
locking,
> timeouts etc.
> b) allow us to mix-and-match Spool implementations with MailRepository
> implementations (eg - use a db for spool locking, but a file-based
> MailRepository)
> c) allow us to use a locking mechanism like the current one (using a Lock
> object) for single machine implementations (if this was more performant).
> d) later we can switch to a dedicated lock-server component more easily.
>
> >
> > 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.
>
> +1
> - I reckon this is the right direction, whether we split the
SpoolRepository
> and MailRepository implementations or not.
>
> >
> > 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
