torque: object pooling/storing of passwords in files

[Subhash Sankuratripati <su...@yahoo.com>]

Hello,
	I would like to use torque(w/out turbine) in our
project and would run it in either websphere or a
weblogic application server..

I have a few questions that I would appreciate if you
guys could answer..

o) Has any body used torque with Entity Beans, using
torque as the Bean managed persistence enabler?. It
can be done, but is it worth it?.

o) Does it pool the Base objects, or does it create
them every time?.

o) Are there any other alternatives to storing the
password in the properties file itself?.

o) Is there any specific reason why the default code
generation for selects does not use doPSSelect, and
does the doSelect instead?. I have a read in the mail
list archives that the best way to use select
statements is to change the doselect() call to a
dopsselect() call

o) This is my managers question :-) :Does it have any
known issues with performance under heavy loads?.

o) Also which version of torque is really independent
of turbine?. is the 3.0b1 or the 2.1?. I could get the
2.1 version of the file from the turbine release
directory.

o) Does torque have any transaction manager of its
own? from the looks of it, it looks like it is not.



Thanks in advance, -Subhash.


__________________________________________________
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: torque: object pooling/storing of passwords in files

[Bill Schneider <bs...@vecna.com>]

Subhash:

Glad you like what you see of Torque so far.  Let's see if I can answer any
of your questions:

> o) Has any body used torque with Entity Beans, using
> torque as the Bean managed persistence enabler?. It
> can be done, but is it worth it?.

Don't know offhand, but it would make sense in the context of bean-managed
persistence. There are definite parallels between the Torque world and EJB:
Torque OM classes Peers  correspond roughly to entity beans and EJB "home"
interfaces.

> o) Does it pool the Base objects, or does it create
> them every time?.

No object pooling (that I know of) but remembers the properties and
associations for an object, to limit redundant query execution on any
particular object instance.

> o) Are there any other alternatives to storing the
> password in the properties file itself?.

Not yet.  One thing I'd like to see (and might get around to working on it
too, someday :-)) would be for Torque to take advantage of any
javax.sql.DataSources that might be available through a JNDI context.  This
would get the business of specifying the db URL, password, etc. in the
properties file. The props file could just contain a name reference instead.

There may already have been some work done on this; I've seen a branch in
CVS for JDBC datasources but not sure where this stands.

> o) Is there any specific reason why the default code
> generation for selects does not use doPSSelect, and
> does the doSelect instead?. I have a read in the mail
> list archives that the best way to use select
> statements is to change the doselect() call to a
> dopsselect() call

Couldn't answer that either. ;-)

o) This is my managers question :-) :Does it have any
> known issues with performance under heavy loads?.

Torque's performance will always be heavily dependent on how it's being
used, and for any given system using Torque, there will be many factors
besides Torque's mere presense that affect persistence performance.
(Indexes, data model design, etc)

 I don't know of a good benchmark for evaluating persistence/OR engines to
compare Torque against competing tools.  You will always get better
performance by hand-crafting each individual SQL statement, and ignoring OR
tools altogether, but you'll pay a price for this in terms of code
maintainability.  Life is a trade-off. :-)  At least Torque makes it easy to
escape into native SQL when you can't live without it.

> o) Also which version of torque is really independent
> of turbine?. is the 3.0b1 or the 2.1?. I could get the
> 2.1 version of the file from the turbine release
> directory.

They both can be used independently of the rest of Turbine, although last
time I looked 2.1 also included a lot of other Turbine support classes that
you need to get that version of Torque up and running.  For instance 2.1
depended on the Turbine logging service, where 3.0 uses log4j directly.  Not
sure if this is true anymore.

> o) Does torque have any transaction manager of its
> own? from the looks of it, it looks like it is not.

BasePeer has methods beginTransaction and endTransaction, which effectively
mean "turn auto-commit off" and "commit and turn auto-commit back on". So
you can do transactions but they aren't really managed (i.e., no support for
JTA and you can't "join" a transaction in progress).

 hope this is helpful!

-- Bill



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: torque: object pooling/storing of passwords in files

[John McNally <jm...@collab.net>]

Subhash Sankuratripati wrote:
> 
> Hello,
>         I would like to use torque(w/out turbine) in our
> project and would run it in either websphere or a
> weblogic application server..
> 
> I have a few questions that I would appreciate if you
> guys could answer..
> 
> o) Has any body used torque with Entity Beans, using
> torque as the Bean managed persistence enabler?. It
> can be done, but is it worth it?.
> 
> o) Does it pool the Base objects, or does it create
> them every time?.

torque-3.0 has Managers which use JCS (from turbine-stratum) to cache
the objects.  Pooling has not been added.

> 
> o) Are there any other alternatives to storing the
> password in the properties file itself?.

I have been working on this, though when I started there was not an open
source connection pool available as a standalone product.  I started
commons-sandbox/jdbc2pool to create such a pool.  There are two versions
one based on torque's current pool and one based on dbcp.  There is also
a Datasource /ObjectFactory arrangement in dbcp that can work though it
does not currently implement PreparedStatement pooling.  As these
alternatives now exist, I have merged the branch for separating the
connection pool back into my working copy.  I plan to commit this after
3.0 final is tagged.  It would probably be enough of a change to get a
quick 3.1. 

> 
> o) Is there any specific reason why the default code
> generation for selects does not use doPSSelect, and
> does the doSelect instead?. I have a read in the mail
> list archives that the best way to use select
> statements is to change the doselect() call to a
> dopsselect() call
> 

Changing the default to doPSSelect would be good.  Especially given
prepared statment pooling.

> o) This is my managers question :-) :Does it have any
> known issues with performance under heavy loads?.
> 

no.

> o) Also which version of torque is really independent
> of turbine?. is the 3.0b1 or the 2.1?. I could get the
> 2.1 version of the file from the turbine release
> directory.
> 

3.0

> o) Does torque have any transaction manager of its
> own? from the looks of it, it looks like it is not.
> 

no

> Thanks in advance, -Subhash.
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Sports - live college hoops coverage
> http://sports.yahoo.com/
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>