james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Problems using Derby for stores
Date Fri, 18 Nov 2005 13:12:12 GMT
Danny Angus wrote:
> Daniel John 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

My presentation was about portlets.  I wonder if he means at the one on
JAMES, which you also attended.  In any event ...

> 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'm happy if we can rely upon the presence of a SQL database in JAMES,
although I disagree that we can so easily deprecate non-SQL stores, at least
for messages.

> > 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

I thought that we had setup Derby as the default database already.  I'll
take a look.  The only thing is that DB isn't the default store.  I could
change that, at least for now, so that we get more testing on that code.

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

I'm not quite sure what that would mean to embed JAMES.  JAMES, itself, is
made up of multiple services that are embedded in an Avalon container.  But
I would like to investigate how we can better make use of a database as
core, rather than as ancillary.  We're also looking at the idea of using
something like JMS for messaging, but I'm still not convinced which way
would be best to go, be it a database, JMS or even JavaSpaces type solution.

Any comments on this?

Arguably, looking at the options for JMS and other messaging schemes, a good
database might be the most effective solution, since none of the others give
us particularly good query capabilities to filter what we want at any given

> being able to using triggers with spools would be superb

Yes, but it would impose requirements on what we could use for the
technology in that layer.

> > 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.

We already try to do some of that within the spool, but the idea of a global
mail transaction would be quite interesting.

	--- Noel

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

View raw message