Alan Greenspan wrote: > Section 11.3.3 of the spec shows an example of a session bean that uses a 11.3.4 in my copy of the 1.1 spec. But there are so many... > > couple database connections in a transaction. The interesting thing about > this code is that the database connections are acquired before the > transaction is started: > > ... > con1 = ds1.getConnection(); > stmt1 = con1.createStatement(); > ... > con2 = ds2.getConnection(); > stmt2 = ds2.createStatement(); > ... > ut.begin(); > stmt1.executeQuery(...); > ... > > With this coding style, when would the resources associated with the > connections get enlisted with the transaction manager and associated with > the transaction? If the container interposes on the getConnection, it can > enlist the resources with the transaction manager, but can it do it before > the transaction is started? Certainly, the JDBC driver isn't going to do > it in the Statement implementation. > The resources will be enlisted when ut.beginTransaction is called. The container keeps track of the transactional resources allocated by each thread and associates them with any transaction the thread starts. Closing the connection dissociates the resources from the thread. The troubling code to me is the example previous to this one, where no UserTransaction is started at all, but instead the bean calls the transaction APIs directly on the database connections.
begin:vcard n:Wilson;Chip tel;fax:(214) 358-0353 tel;work:(214) 642-4559 x-mozilla-html:TRUE url:http://www.axyssolutions.com/ org:Axys Solutions adr:;;;Dallas;TX;; version:2.1 email;internet:[EMAIL PROTECTED] title:Application Architect note:Sun Certified Java Architect x-mozilla-cpt:;-25088 fn:Chip Wilson end:vcard
