> I can think of four alternatives for db support in james: town, jdbc,
> avalon, turbine.
>
> 1) Stick with town.
> Pros: (per serge) Abstraction across multiple drivers, simpler than
> JDBC, connection pooling
> Cons: (serge) forces message instantiation
> (charles) how active is the town community?
seems quite inactive recently - but we could reactivate it :). It would be
great to have a good open source Object-Relational mapping solution and
Town seems to be a good start - I don't know how far the other projects go
down that route.
> 3) Avalon (jakarta)
> Pros: provides pooled connections,
> Cons: don't know much about this, possibly limited community at
> present (Avalon & cocoon)
>
> 4) Turbine (jakarta)
> Pros: provides pooled connections, Peer object (OR mapping)
> Cons: don't know a lot about this, either!
Turbine seems to be the best supported right now. Possibility - merge Town
and Turbine - i.e. take the OR Mapping stuff from Town and move it into
Turbine? Anyone active in the Turbine lists?
Steve
>
> The advantage to Turbine or Jakarta is that they provide more
> functionality than plan jdbc but, I guess, with more support than town.
>
> Thoughts?
>
> Charles
>
>
>
> Serge Knystautas wrote:
> >
> > 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]
>
> ---------------------------------------------------------------------
> 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]
