Steve,
I really have had no time to do anything for the JAMES project. I think
moving from Town to JDBC is good option because Town instantiates a blob
completely (the MimeMessage), while with JDBC we could get the blob as a
stream. This would potentially halve the memory requirements when
processing a message (and accordingly speed things up)...Town takes the blob
and gives you a byte[], then this gets streamed to the constructor of a
MimeMessage. If we used JDBC, we could get the stream directly and get rid
of the intermediate byte[].
I think there were other issues as well, but this sticks out at me as the
biggest issue. The nice parts of Town for James in my mind is the built-in
connection pooling, the simpler code (although most people won't understand
it as easily as they would JDBC), and the abstraction across multiple JDBC
drivers (since there seem to be variations that might cause incompatibility,
or require us to hardcode so support).
Sorry, I'd like to say I have something to report, but again, I just don't
have any time these days.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
----- Original Message -----
From: "Steve Crossan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 5:44 AM
Subject: Town replacement
> Serge
>
> You spoke quite recently about wanting to replace the Town DB interface
> with some custom written jdbc to improve performance. Do you have any more
> info about progress on this? Would an alternative be to work on the Town
> code to try and improve it's performance - since it has some great
> features (esp. the ORMapping).
>
> thanks
>
> Steve
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
