----- Original Message -----
From: "Stefano Bagnara" <[EMAIL PROTECTED]>
To: "James Developers List" <[email protected]>
Sent: Monday, March 06, 2006 11:54 AM
Subject: Re: MimeMessage handling optimizations/changes for 2.3.0a2
Markus Kühn wrote:
I didn't and wouldn't change MimeMessageJDBCSource with all the problems
and side effects you described. I found storing the body of big messages
by default in the file system to be the best solution for me so far.
Well, I use db repositories because I need a good failover solution and
simpler backups. Most db provide replication, also.
When all the data is in a single place it's much more easy to manage it
and avoid "synchronization" problems between filesystem and db data.
Enabling replication or fail over for files shouldn't be hard.
Administrators just have to be aware of the situation, that they could
activate or deactivate an OutofMemory-safety by using dbfile for big
messages.
The changes to MimeMessageJDBCSource are needed for DB repositories while
your solution is good for messages created from scratch.
From scratch and also existing messages on the file system, as you pointed
out below.
Using dbfile or file repositories we can just use the SharedInputStream
from the stream repository (patch pending).
I think the biggest problem with dababase streams is, that they do work only
with some databases.
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
