Hi, > -----Original Message----- > From: Extance, Paul [mailto:paul.extance@;spirent.com] > Sent: 31. okt�ber 2002 17:57 > To: 'Tomcat Users List' > Subject: RE: JDBC / ThreadLocal pattern. > > So the theory is good, but if you going to have a connection > pool anyhow, this is just a lazy way to pass the connection > around. Still seems like overkill if many calls don't need to > use the database for anything... I guess you could be lazy > and only get the connection from the pool and bind it to the > threadlocal just before you use it for the first time.
Behind the java object representation of our data, there is a pluggable peristence layer. In most cases, this layer will be using a JDBC connection to implement the persistence functionality, but in some cases this may be implemented by writing to flat files, XML files or whatever. This is of course over-abstraction, but the data model is actually being used in several other settings as well, so this is expected to pay off. this is equivalent to the "lazy way to pass the connection around", but we've got a slightly better reason. I suppose a PersistenceConnection interface could be defined and an implementation of that would wrap a JDBC connection, etc, etc, but this is more cumbersome and requires additional justification. > 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? Me� bestu kve�ju, Reynir H�bner -- To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
