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]>
