Assuming you did want a shared repository (which sounds like a nice idea),
you'd really just want to reimplement the locking mechanism to use the
database. In that case, you'd want to probably store this in another table
in the database (?), and figure some way to unlock messages that are stuck
because a server crashed. A simple way is to build the lock name for a
server based on the hostname, and when it starts up, have it clear all the
locks created from itself (so, if I'm on mail1.domain.com, I would delete
all the locks by mail1.domain.com). It means that you could get some locks
stranded if mail1 crashed, but then when mail1 started back up, things would
be fine again.
You could also expose an RMI service or (XML-RPC or SOAP or something else)
so that each instance of James would communicate with a single service to
lock/unlock messages.
Just throwing out ideas...
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 07, 2001 10:13 AM
Subject: RE: Can 2 instances of JAMES share the same database?
>
> Thomas Jachmann had an interesting idea about keeping the spool
> repositories separate (by either keeping them on the local disks,
> or pointing at different tables in the db).
>
> Do you think this would successfully avoid the locking problem?
>
> Thanks,
> Bruce
>
> -----Original Message-----
> From: Oki DZ [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, August 07, 2001 4:09 AM
> To: [EMAIL PROTECTED]
> Subject: Re: Can 2 instances of JAMES share the same database?
>
>
> On Mon, 6 Aug 2001, Serge Knystautas wrote:
>
> > There's a problem with the spool managers as locks are handled within
each
> > given instance. This means it's possible that a message could arrive in
> the
> > spool repository, and both mail engines would try to process it. Aside
> from
> > this locking issue, I think things would be fine.
>
> And due to the locking issue, you may have the messages get sent twice.
>
> Oki
>
>
>
> ---------------------------------------------------------------------
> 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]
