Hi Thomas, thanks for your answer.
> Torque does not have its own transaction mechanism, it uses jdbc > transactions. Yes, I'm aware of this. But Torque implements a kind of tx behavior when a method like doInsert() is called without passing a connection. In these methods in BasePeer, always a COMMIT or ROLLBACK is executed - what we don't want as the Container, Bea here, should handle the Tx. The bahavior of the container is configured in the deployment descriptor, of course, normally on business method level. A transaction type may be "RequiresNew", "Mandatory" and so on. > The transactional behaviour is different for different databases. > E.g. for oracle, the first select/update/insert... command automatically > starts a transaction, whatever you do. I cannot see that, though. I don't find a location in Torque's code where the Transction is handled dependent on the adapter or so. Where do I have to look? That is our solution by now: As generated BasePeers call statical methods on their superclass BasePeer _directly_ (e.g. "BasePeer.doInsert(...)"), I wasn't able to hook in a class overriding some of BasePeers behavior. So I changed the "Peer.vm" template so that it does _not_ call BasePeer in its e.g. doInsert(Criteria) method, but my base peer class as configured in the schema.xml. So, I can override BasePeer and implement my own transaction behavior in the methods that don't take a connection. The benefit: I don't have to care about fetching and returning connections in the countless generated Peer classes. I just can use doInsert(Criteria) or save() like used to. The thing I don't like: I had to change the torque-gen.jar. Besides that, the changes were very minor but effective. My question, however: has anyone used Torque with container managed transactions before? And if yes: how? Bye, Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
