When connections are returned to the pool, they loose their transactional
 information which they inherited from the context.

 Also, when doing multiple operations on the same connection, all of the
 operations are under the same transaction umbrella and do not
 affect other transactions.

 And since you really don't seem to be concerned with the likelyhood of
 concurrency, your use of serialized transactions ensures that you won't see
 other transactions effects and locking should not be that huge a concern.

 The issue between pessimistic and optimistic transactions really lies in
 what trade offs you are willing to pay. The more isolation, the more
secure
 you are and the less you have to do on your side. But the penalty is
 locking, key, page, and extent, or worse, table. And the loss of
 performance. If you are not concerned with the locking and performance
 penalties, then serializable isolation is for you. But, since you don't
 seem to think that the data will be accessed concurrently, why bother other
 than for the roll back capability?

 The sessions you create simply enlist in the transaction, and are released
 when they are placed back into the pool.

 So I am wondering, what is your real question if you are having if you have
 already decided that concurrent usage of records is not an issue and you
are
 using a serializable isolation level.

----------------------------------------------------------------
Users Guide http://discuss.microsoft.com/archives/mailfaq.asp
contains important info. Save time, search the archives at
http://discuss.microsoft.com/archives/index.html .
To unsubscribe, mailto:DCOM-signoff-requestDISCUSS.MICROSOFT.COM

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]