I have modified the Entity Mailbox to hold a serialized copy of the mail body.
I think there is enough of the store in place now that the new mailbox
implementation could be integrated. Most of the changes outstanding for the
store will be behind the Store interfaces (e.g. configurable
anonymous wrote : Postgres's latest drivers seem to support streaming.
Sort of, streaming is supported via JDBC2 for inputing into a byte array field,
but not for retrieving data. Also the JDBC3 Blob is not supported, our
implemenation uses this (I sent a patch a couple of weeks ago but have
No data migration. Use POP, download your emails then install M3 :-). The
type 3 should be a configurable size. For instance I might only want mails
above 4k in the store and the rest cached. that'd give me a good compromise.
View the original post :
Postgres's latest drivers seem to support streaming. They do so in 4k blocks,
but thats pretty okay.
There is another reason to use the store :-). JBossMQ...it...well makes
multiple copies of the body.
Ultimately we will need BOTH behaviors (Store and No Store). For this release
Ok. I will get to work on integrating the message store into the main line.
The body of the Mail will become a seperate object (currently it is a List of
byte arrays) which will be a proxy to the Store.
When I have that done I will modify the hibernate implemenation such that it
implements a
I have just commited the latest update to my store code. The JDBC3 and
PostgreSQL module play nice the JBoss Client Transaction Manager now.
Currently it has similar behaviour to the EJB Required transaction type,
mainly because the Client Transaction Manager doesn't support nested
Ultimate desired behavior:
When DATA is coming in (via the CmdDATA) we start creating a Mail (via
Mail.java or whatever). If the size exceeds N bytes we instead create a mail
store. The Mail now points to the mail store.
Acceptable behavior for M3:
When DATA is coming in, it is immediately
To be clear...the Mailbox should Point to the message store. The Body should
go in the store, the Mailbox should use the store. We don't trust what is in
the store to be valid as a mail or that we'll even not throw it away.
Eventually we'll even want code to reap the unattached bodies
The idea behind the design is to be a portable implementation that should run
as is on almost any database, based on the services provided by hibernate.
I have tested it on blobs of 10MB, and it performs pretty well on Portgres. It
does however consume large amounts of memory since it is not a
yeah...you guys figure out how to integrate and work together I kinda
favor the sender being in the mailbox too. However what is more important is
that you guys establish a working relationship and communicate... Thats more
important to me strategically (goes for everyone).
View the
My Store stuff is fairly close. I need to do some work to finish off the
handling of transactions and I should be able to commit around the end of this
week.
However there is a task assigned to me (JBMAIL-25) that recommends that the
store stuff I have done be reworked to implement
There is no methods that support doing partial reads/writes:
You are correct. The current implementation uses Hibernate for persistence,
with no support for patial reads afaik. The mailstore interface should be
adapted to allow it if a store supports it. It would probably mean adding
12 matches
Mail list logo
