Lightweight transactions vs. Connection pooling

The problem is that, as instructed, we've duly stuck to the "connection pooling" model of using and releasing them ASAP. However, this means that I'd have to change *all* the code to pass the connection around, surly that would mean that connection contention would slow down the throughput. "Between a rock and a hard place", no?

pkr2000 at 2007-8-30 >

The second point is closer the mark. The inner components have no idea (and nor should they) what transaction they're in, that's the responsibility of the controller component. However, the majority of them do need to open database connections and do need to get the uncommitted data associated with the ambient transaction. I don't (think) I have a problem with that. What I find odd is that given the connection pooling works by understanding you're asking for exactly the same connection why can't the LTM understand that it doesn't need to promote the transaction? I'm sure there are reasons for it, but I'm sure people of your vast intelligence could get around that issue therefore providing the connections were always to exactly the same provider the LTM would have no need to promote to the DTC and we'd all have a wonderful lightweight experience!

pkr2000 at 2007-8-30 >

I believe Jian answers all your questions on her final post on the thread that you are pointing to.

Bottom line is that the only way to avoid this at the moment is to have a single connection, this pooling limitation may be removed in the future. to make sure of this I would make sure a bug is entered in the product feedback site (or voted on if there is already one there).

Angelsb at 2007-8-30 >