oops, Sorry, didn't see John's reply about the JCS and Torque.
Scott > -----Original Message----- > From: Weaver, Scott [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, March 20, 2002 10:04 AM > To: 'Turbine Users List' > Subject: RE: torque: object pooling/storing of passwords in files > > > > > 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]> > > >
