> > 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.
>From what I have seen lately (someone correct me if I'm wrong), I think there has been talk about using JCS, <http://jakarta.apache.org/turbine/stratum/JavaCachingSystem.html>, wihtin Torque via a "Manager" class. That's all I know. I currently use Turbine Global Cache to cache my most used Torque objects. p.s. After reading about JCS, I'm VERY excited to see some good examples JCS with Torque! There was mention of a possible document being availble early this week sometime on the subject of JCS with Torque. Is this available yet and if it is, where is it located? Regards, Scott > -----Original Message----- > From: Bill Schneider [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 12:05 AM > To: Turbine Users List > Subject: Re: torque: object pooling/storing of passwords in files > > > 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: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
