On Thu, 9 Aug 2001 01:08, Serge Knystautas wrote:
> 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'm sure you're more familiar with this than I, Serge. As I said, I was just
thinking (out loud, I guess). I hope it didn't create too much noise :-)
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
