You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Steve Crossan <st...@runtime-collective.com> on 2001/05/08 11:44:52 UTC
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: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
That would be great. If you send tested files/ patches to this list,
someone can add them to CVS.
You might want to start with MailRepository. We need to rethink
UserRepository to handle encrypted passwords, changing passwords,
forwarding and aliasing.
Charles
Steve Crossan wrote:
>
> Seems like Peer/Turbine is worth investigating. I'm happy to do a bit of
> research into this - try and port the James/Town stuff to James/Peer.
>
> Steve
>
> http://www.runtime-collective.com
> t: 01273 234290
> f: 01273 234291
> m: 0789 984 1684
>
> On Tue, 8 May 2001, Jon Stevens wrote:
>
> > on 5/8/01 11:17 AM, "Harmeet Bedi" <hb...@yahoo.com> wrote:
> >
> > > FYI: 2 other open source ORM projects that could be interesting are
> > > DODS from Enhydra http://dods.enhydra.org/
> > > Castor from Exolab http://castor.exolab.org/
> > >
> > > Harmeet
> >
> > DODS, I don't know much about, but on the Enhydra.org site, they suggest
> > they are moving to Osage.sourceforge.net which is *very* similar to Turbine
> > Peer's and in fact used to be in Turbine's source tree, but the author
> > didn't want to be in Turbine's shadow.
> >
> > Castor is ok, but it is bloated and does way to much. The Jetspeed project
> > currently uses it but is moving away from it (probably towards Peers).
> >
> > So, the question would really be Peer's or Osage. I would choose to eat my
> > own dog food. :-)
> >
> > -jon
> >
> > --
> > If you come from a Perl or PHP background, JSP is a way to take
> > your pain to new levels. --Anonymous
> > <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Steve Crossan <st...@runtime-collective.com>.
Seems like Peer/Turbine is worth investigating. I'm happy to do a bit of
research into this - try and port the James/Town stuff to James/Peer.
Steve
http://www.runtime-collective.com
t: 01273 234290
f: 01273 234291
m: 0789 984 1684
On Tue, 8 May 2001, Jon Stevens wrote:
> on 5/8/01 11:17 AM, "Harmeet Bedi" <hb...@yahoo.com> wrote:
>
> > FYI: 2 other open source ORM projects that could be interesting are
> > DODS from Enhydra http://dods.enhydra.org/
> > Castor from Exolab http://castor.exolab.org/
> >
> > Harmeet
>
> DODS, I don't know much about, but on the Enhydra.org site, they suggest
> they are moving to Osage.sourceforge.net which is *very* similar to Turbine
> Peer's and in fact used to be in Turbine's source tree, but the author
> didn't want to be in Turbine's shadow.
>
> Castor is ok, but it is bloated and does way to much. The Jetspeed project
> currently uses it but is moving away from it (probably towards Peers).
>
> So, the question would really be Peer's or Osage. I would choose to eat my
> own dog food. :-)
>
> -jon
>
> --
> If you come from a Perl or PHP background, JSP is a way to take
> your pain to new levels. --Anonymous
> <http://jakarta.apache.org/velocity/ymtd/ymtd.html>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Jon Stevens <jo...@latchkey.com>.
on 5/8/01 11:17 AM, "Harmeet Bedi" <hb...@yahoo.com> wrote:
> FYI: 2 other open source ORM projects that could be interesting are
> DODS from Enhydra http://dods.enhydra.org/
> Castor from Exolab http://castor.exolab.org/
>
> Harmeet
DODS, I don't know much about, but on the Enhydra.org site, they suggest
they are moving to Osage.sourceforge.net which is *very* similar to Turbine
Peer's and in fact used to be in Turbine's source tree, but the author
didn't want to be in Turbine's shadow.
Castor is ok, but it is bloated and does way to much. The Jetspeed project
currently uses it but is moving away from it (probably towards Peers).
So, the question would really be Peer's or Osage. I would choose to eat my
own dog food. :-)
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Harmeet Bedi <hb...@yahoo.com>.
----- Original Message -----
From: "Steve Crossan" <st...@runtime-collective.com>
> 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.
FYI: 2 other open source ORM projects that could be interesting are
DODS from Enhydra http://dods.enhydra.org/
Castor from Exolab http://castor.exolab.org/
Harmeet
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
Steve Crossan wrote:
>
> > 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?
I've only just started with Turbine, hence not up to speed. But the Peer
classes and torque may do the trick.
Charles
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Turbine and Torque (was: Re: Town replacement)
Posted by Jon Stevens <jo...@latchkey.com>.
Peers are *the* right solution. I'm biased of course.
Torque itself is abstracted from Turbine. Torque is the tool that you use to
build the generated .sql and the .java files from a .xml file input. This is
what builds the OR mapping.
Those files do indeed depend on *parts* of Turbine (not all of it). So, it
comes down to a packaging question. At this point, we (the Turbine project)
have given up the idea of trying to package the connection pool and the Peer
related base classes separate simply because including a single
"turbine.jar" (and JDBC / Village) in your classpath isn't that big of a
deal.
Runtime configuration is easy. It is done through the
TurbineResources.properties file and external usage is configured using the
TurbineConfig.java object (see the javadoc for details). It is really easy.
Turbine now has a deprecation policy. This is something that I'm going to be
very religious about following (simply because I wrote it and because I'm a
Sam believer).
<http://jakarta.apache.org/turbine/deprecation.html>
The Peer stuff is being used quite a bit now by a lot of people. I'm using
it in my Scarab project and CollabNet uses it as the basis for DB stuff in
their core product and there are several other companies using it as well.
The number of questions on the Turbine-user/dev list regarding Peers has
gone up quite a bit (meaning more people are using it).
Performance is of course not as good as straight JDBC, but that is the
tradeoff. Easily maintainable code or not. So far, we have not been able to
directly point to Peers as being a bottleneck though (in other words, there
is other stuff in most systems that is much slower).
Documentation for Peers/Torque is on the Turbine website and in the javadocs
for the classes. It isn't perfect, but we now have a "Turbine Documentation
Team" which is working on improving things. The stuff that is up there is
definitely enough to get started.
Turbine will be released at JavaOne as version 2.1. We have already branched
the CVS tree to work towards a 2.1 stable while the MAIN has continued
development.
I guess the summary is that it is a fully supported product within Turbine
that does the job very well and there is a lot of people using it.
You make the decision.
-jon
--
If you come from a Perl or PHP background, JSP is a way to take
your pain to new levels. --Anonymous
<http://jakarta.apache.org/velocity/ymtd/ymtd.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Steve Crossan <st...@runtime-collective.com>.
> 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" <st...@runtime-collective.com>
> > To: <ja...@jakarta.apache.org>
> > 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: james-dev-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Peter Donald <do...@apache.org>.
At 02:31 8/5/01 +0100, Charles Benett wrote:
>3) Avalon (jakarta)
> Pros: provides pooled connections,
J2EE style - easy to pester main developer ;)
> Cons: don't know much about this, possibly limited community at
>present (Avalon & cocoon)
Doesn't do any management or cross vendor SQL mapping. Which means the SQL
has to be read in from config files (ewwwww).
>4) Turbine (jakarta)
> Pros: provides pooled connections, Peer object (OR mapping)
I haven't looked at it in a while but it used to be (and probably still is)
the best DB pooling around. Cross-DB, well tested and it also has OR-style
mapper ala torque.
> Cons: don't know a lot about this, either!
It was also fairly tightly integrated into turbine. Not sure if this has
changed or not. Extracting it could be a pain but may be a useful excercise
for commons ;)
Cheers,
Pete
*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof." |
| - John Kenneth Galbraith |
*-----------------------------------------------------*
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Charles Benett <ch...@benett1.demon.co.uk>.
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?
2) Straight JDBC
Pros: probably widest community, maximum flexibility
Cons: need multiple drivers, need connection pooling, requires
lower-level coding
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!
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" <st...@runtime-collective.com>
> To: <ja...@jakarta.apache.org>
> 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: james-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: james-dev-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org
Re: Town replacement
Posted by Serge Knystautas <se...@lokitech.com>.
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" <st...@runtime-collective.com>
To: <ja...@jakarta.apache.org>
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: james-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: james-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org