Hello Stefano,
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.
Then it is as I feared ;)
I suggest you to read this too:
http://wiki.apache.org/james/HandlingExceptions
I already read it before, but I think it will not help me with the
problem of doing a rollback on the current transaction. All I can do to
hande exceptions is send the mail to another processor, which will spool
the mail in between. I guess the best way will be to surround all my
mailets with a try/catch block that does the rollback.
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.
Ok, no problem for me here because I don't rely on Mail identity via
Java Object identity. I also see that this is the reason why I can't put
the Transaction into the Mail's Attributes (they have to be Serializable).
Use a transaction for a processor and not for the whole spooling or it
won't work.
Sounds resonable, will do.
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 see.
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).
Are there any plans to support other databases? Does it suffice to add
the correct statements in sqlResources.xml? In particular I would like
to see firebird support. Maybe I can do that myself and contribute it.
BTW, please keep in mind that SMTP by specification does not ensure you
...
This is really important to know when you start being worried of
transactionality.
Does the Message-ID does help in such cases? Unfortunately not all mails
have one, but that's another story...
thanks a lot for your insights,
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
