Re: Input for JDB Mail Repository

[Serge Knystautas <se...@lokitech.com>]

I understand the shared resource issue and will probably go ahead and make
that body to the file system optional.  Also note though that you couldn't
have multiple james server accessing the same DB because then you would have
no way to centrally manage the locking of messages.  Perhaps a later
enhancement. :)  Remember you could also store the files on a shared network
drive.  Seems like there's a need for a lot of flexibility here.

Again the motivation for putting body in the filesystem was purely
performance... I did a test with JDBC and took over a minute to process a
meg email.  I did the file system (no JDBC at all), and it took a fraction
of a second of CPU time (since it never instantiated the message in my
proposal code).  So by storing the body in the file system, I get most of
the performance and most of the searching. :)

Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Danny Angus" <da...@thought.co.uk>
To: <ja...@jakarta.apache.org>
Sent: Tuesday, July 31, 2001 7:47 AM
Subject: Re: Input for JDB Mail Repository


>   Serge Knystautas <se...@lokitech.com>  Wrote:
> >Charles,
> >- I've written the JDBCMailRepository to store message bodies in the file
> >system.  Even after all this work to not parse messages, a large message
(a
> >meg or more) would still bring my JDBC driver to a crawl.  Now, the
> >JDBCMailRepository will store all delivery information and the message's
> >headers to the database, and the message body separately to the file
system.
> >It's hopefully written in such a way that you could turn this off and on,
as
> >it should already read a message that is entirely stored in the database
and
> >so you'd just have to change how it saves messages.
>
> This sounds a little dodgy, I can see why you would want to do this, but
don't forget the scenario whereby several machines are all accessing a
seperate db machine/cluster the filesystem model would breakdown there.
>
> One of my overiding aims is to see James feeding into, and reading from, a
db which can also be accessed by applications (servlets probably, but not
necessarily) which would probably be accessing a common db from a cluster of
app/web servers.
>
> I would like to see webapps given mail access by dumping messages into the
repository, then have James deal with transporting them in any way it sees
fit. Much like pipeing messages to sendmail.
>
> Likewise I'd like to see, for instance, other applications have the
ability to search and retireve messages from the db based on message
content. I'm using webmail to write this message, I currently have 96
messages in my mailbox, how nice to be able filter/search and sort them
on-line like I do when I'm using outlook. If the message body is not in the
db this wouldn't be as trivial a task as generating SQL.



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