Michael Weissenbacher ha scritto:
What happens if an error occurs and the mail is sent to the error
processor? If I understand correctly the error processor may be handled
by a different thread. In that case it's not OK to rollback the current
ThreadLocal transaction there: It might be a different one because James
may have picked another thread from the pool. Am I right here?
Once the mail is store into the error processor the current thread has
no more tasks to do. Another thread will pick up the mail from the error
state and run it through the error processor.
I suggest you to read this too:
http://wiki.apache.org/james/HandlingExceptions
When the mail is read from the spool aa new Java instance is created,
so it is instead probably true that a single java instance of a Mail
object will be processed by a single thread, but James will use
multiple java instances for a single mail processing.
What exactly do you mean with multiple Java instances? Multiple
Instances of MailImpl or multiple instances of Thread or both?
From one processor to another a Mail is persisted and read from the
persistence. From a Java point of view a new instance of the MailImpl
object is created every time you retrieve a mail from the spool.
Mail m1;
spool.store(m1);
Mail m2 = spool.retrieve(m1.key);
m1 and m2 are 2 different java instances of the same logical mail.
The spool processing is not a short running operation and IMHO it is
not suggested to have transactions running from the beginning to the end.
My current processing takes <300ms, which isn't too bad for the life
span of a DB transaction IMO. I don't like the idea of starting and
commiting 10+ transactions for the processing of a single mail for both
performance and safety.
Use a transaction for a processor and not for the whole spooling or it
won't work.
Keep in mind that unfortunately our spoolmanager is not (yet)
transactional: there are no atomic processing. This could lead to
duplicated processing: this is not a BIG issue because SMTP
specifications already ensure that we receive at least 1 copy of each
sent message but it does not ensure we'll receive only 1 copy.
It would be really nice if it could be made transactional (IMHO) at
least inside a single processor. It could be a major selling point vs.
other mailers. I understand that this can only work with a DB backend
and would be a major effort. Have you ever looked into Hibernate, it
supports virtually all major DBMS's.
Yes, it would be nice, but it is harder than it seems: we don't have
only JDBC operations, so we would need to support XA and require the use
of only transactional resources.
I know very well hibernate, but we don't plan to ever use it because of
licensing issues (LGPL is bad) and because it would probably be overkill
for our simple SpoolRepository scenario. We instead should better have
fine grained control on how we store and retrieve data (e.g: we can read
large streams in a better way than what hibernate could allow us).
BTW, please keep in mind that SMTP by specification does not ensure you
that you will receive a single copy of a message: this is a known issue
of SMTP (a specification) and no SMTP server will be able to save you
from this.
If the connection is interrupted after an SMTP server sent the reply to
the "." of the DATA stream and before the client is able to read the
reply, then the client will send it again, and the server will not be
able to know what happened and will reprocess the same message again.
This is really important to know when you start being worried of
transactionality.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
