Can't we wrap all this kind of external functionalities into the Delivery or
LocalDevlivery servlets so that all external operations will be really
accomplished when the mail is delivered?

Anyway we should pay attention to this choose: we can make a big mistake
here introducing a painfull overhead.

----- Original Message -----
From: "Serge Knystautas" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, February 05, 2000 5:53 PM
Subject: Transaction aspect of messages


> I have to retract my support of keeping messages completely in memory
> until they have 100% completed processing.  If a mail servlet forks a
> new message or communicates with something outside the mail server (very
> likely... a database to log info, whatever), you lose the ability to
> make isolate the transaction.  For instance, say my mail server first
> logs who sent an email (I want to make sure my users aren't spamming
> people, so I restrict to X messages a day... just an example).  A user
> sends a message to 10 friends... I log 10 messages sent, but to keep
> send the message to "undisclosed recipients" (i.e., no "To:" header).
> This crashes some later mail servlet, so this message fails to process.
> I restart the server a few times until I finally figure out what's going
> wrong, and in the meantime, that log has a record of 10 messages sent
> each time I started the server.
>
> Sorry for the lengthy example... the concept is probably evident enough
> once you consider mail servlets can affect more than the message
> itself... I think you're going to have to restore the message with the
> modified state after each mail servlet to better ensure the
> transaction.  Maybe you could make this an optional setting so people
> can turn it off if they want better performance and aren't as concerned
> about isolated transactions.  However, I'm still not sure how message
> forking would work... how do you keep that as an isolated transaction?
> You don't want that listserv message to generate 10 messages to all
> these new recipients several tiems because some later servlet is
> crashing on that message.
>
> Serge
>
>
> ------------------------------------------------------------
> To subscribe:        [EMAIL PROTECTED]
> To unsubscribe:      [EMAIL PROTECTED]
> Archives and Other:  <http://java.apache.org/>
> Problems?:           [EMAIL PROTECTED]
>



------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/>
Problems?:           [EMAIL PROTECTED]

Reply via email to