Reynir H�bner asked: > > Seems to me that this is the simple question of 'global > > variables' or 'passing parameters' style of coding. The > > 'global variables' approach seems some what less object > > orientated in my opinion (Coming from a 4GL background where > > I was haunted by global variables :-) ) > > Craig worried about having a transaction per user session > which would be very expensive and wouldn't scale beyond > internal testing. However, in the general case, we'd close > transactions at the end of a request. Some times, however, a > user asks for a list of items matching a set of criteria and > we'd then keep the Connection until the user moves away from > the list of results. We'd have a read-only ResultSet from > which we'd lazy-load data as the user pages through it. > > Is there a better way of implementing this kind of > functionality that doesn't entail committing a connection to it?
You might consider reading all of the data from the result set immediately and putting it into some sort of memory structure, then releasing the connection. Then, for each request, present only the portion of the cache that is needed. This has the benefits of: - not tying up Connection resources for an arbitrary time - possibly reducing the number of network round-trips from the app server to the database - depending on what RDBMS and JDBC drivers you're using, possibly reducing SqlExceptions when reading from the result set. (If you're not interested in Oracle internals, you should probably skip the rest of the email.) I am thinking specifically of Oracle in my third point -- with Oracle, query results are guaranteed to be consistent as of the moment in time that the query was submitted. If the underlying data changes in other committed transactions, the point-in-time consistency of the query result set is maintained by using rollback segment information. However, information in the rollback segment can be overwritten by new transactions; if Oracle is unable to maintain point-in-time consistency because the rollback information it needs has been overwritten, reads from the invalid result set cause an ORA-01555 "snapshot too old, rollback segment too small" error, which would then be propagated into the application as a SqlException. Very irritating. I would not be surprised to learn that other RDBMS' are prone to the same sort of difficulty. Cheers, bn -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
