james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Danny Angus <danny.an...@gmail.com>
Subject Re: Problems using Derby for stores
Date Fri, 18 Nov 2005 09:34:07 GMT

On 17/11/05, Daniel John Debrunner <djd@debrunners.com> wrote:
> Danny Angus wrote:
> > Dan Debrunner wrote:

> Thanks for all the info. At ApacheCon Europe I discussed with Noel (in
> his presentation) some of the possiblilities of integrating Derby and
> James, the first step would be Derby as a data store for James.

Yeah, sadly I missed you there, but I spoke to Noel about the same
things, in fact I'd already hacked James to use derby embedded after
using derby at work to embed in a number of log-file analysis tools so
I knew it would work. (It is so cool to be able to use SQL to analyse
logfiles by the way)

> I've downloaded James source and compiled it, and run it, though I
> haven't yet tested sending e-mail to/through it. I briefly looked around
> the James site but didn't see any instructions on how to set it up for
> Derby, any pointers would be appreciated.

There sadly there won't be any, but you can look at the config.xml
database config parts, and sqlResources.xml for the sql dialect stuff,
James can be a bit of a pain to understand at first, I'm not knocking
it but the IoC/Phoenix stuff sadly does a pretty good job of obscuring
it from casual understanding.

> Subsequent possible integrations are James running within Derby to
> provide better e-mail support from procedures, functions and triggers,
> such as e-mail spooling.

That sounds interesting. Our long-term architecture plan is to make
James container agnostic, and prepare deployments by wrapping James
classes in classes which can map container specific lifecycle events &
services onto James' API. We also like the idea that individual parts
of james could be deployed seperately and storage/spooling is
certainly one area that would make sense from an operational point of
Using derby with some parts of James embedded in in in a distributed
James installation would result in an n-tier mail system in which the
datastores are self-contained and "smart". Hmm... James wouldn't need
to manage them, they could manage themselves, exposing a couple of
very simple services. (perhaps I should say DBA's would manage them

being able to using triggers with spools would be superb, you could
use the triggers to notify a sleeping dequeue process that it is time
to wake up, this would eliminate polling and the delays caused by
inappropriate sleep-times, it might mean that we'd need to change the
process that uses the spool to accept pushed notifications, but I
don't think that would be beyond us.

> Then I wonder if transactional e-mail is
> possible, send an e-mail from a trigger, but if the transaction
> subsequently rolls back, don't send the e-mail.

This is 100% possible already if derby manages the spool, even without
embedding either thing in the other because it is OK to insert records
directly into the spool tables already.
You just have to be careful to set appropriate values and validate the
data of course, doing this in a transaction would indeed cancel the
message on rollback. If you get the chance to try it the easy way to
know what values to use is to send a regular mail through James and
query the table to see what it looks like when it is in the spool, the
important bits (the routing and status stuff) are just varchars with
text strings, normalising them into look-up data would allow
validation in the db, but we'd have to do it for all our supported
dialects and we've got little enough time between us to do the
interesting things.

Two very nice ideas, now where did I put my spare time... :-)


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message