Hi Greg, Thanks for your answer. I prefer to do something with db connection pooling. As a understood correctly, you are using another application to deal with the connection db pooling for torque? Or is it a configuration within Torque? If you are using another application, can you tell me whcih one you are using?
Kind regards, Robert Kromkamp -----Original Message----- From: Greg Monroe [mailto:[EMAIL PROTECTED] Sent: donderdag 3 november 2005 16:03 To: Apache Torque Users List Subject: RE: performance > From: Robert Kromkamp > I've got the feeling Torque is al little bit slower than > straightforward queries on the database. Are there some way's > the improve the performance of torque? By example, use caching? In general, there is no denying that an abstract layer will always be slower than a native layer. Code written in Assembler language will always be faster than Java. But why do you use Java instead of Assembler? The same reasons that people give for developing in Java apply to using Torque over native JDBC. You can develop, debug, modify, maintain it faster, better, and cheaper. Remember, the cost of developer time can quickly outweigh the cost of more hardware in today's economics. That said, there are some internals that make Torque perform better. IMHO, number one is using pooled connections. One of the most time consuming JDBC operation is opening a connection to the SQL server. Pooling eliminates this by caching open connections and letting code share them. I've seen actual major performance gain by converting a native JDBC app that did individual connections to Torque. There are also internal tweaks that may or may not help such as the torque.objectIsCaching property that controls whether data objects cache foreign keys or not. I think there are a couple more but am not sure. IMHO, it's REALLY hard to cache at the DB interface level because you don't have any application context. Its really easy to have a caching scheme that speeds up one type of application but slows down another. Personally, I favor caching the information at the object level in the application. For example, cache fairly static, commonly used web application information in the session. Or something that is used repeatedly in processing requests, in the request object. Because this is application context specific, it tends to be more efficient. Well, enough soap-boxing.. hopefully this helps or at least raises more specific questions we can deal with. Greg Duke CE Privacy Statement Please be advised that this e-mail and any files transmitted with it are confidential communication or may otherwise be privileged or confidential and are intended solely for the individual or entity to whom they are addressed. If you are not the intended recipient you may not rely on the contents of this email or any attachments, and we ask that you please not read, copy or retransmit this communication, but reply to the sender and destroy the email, its contents, and all copies thereof immediately. Any unauthorized dissemination, distribution or copying of this communication is strictly prohibited. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
