Hi Chakra
first of all the isolation level doesn't affect the locks applied by pure
modification operations. They will apply the exklusive locks and this locks
will be hold 'till the end of the transaction. So, you're batch job will
cause locks in the db (you can check by using the sp_lock) if it modifies
data (what I suppose according to the problem you described).
Now it depends what your "other classes" are and how they want to access the
data. If they do modifications you might have concurrency confflicts by
design (means there isn't much to do, there are just conflicts). You might
solve this by changing the granularity of transactions, using compensating
transactions to get the atomicity instead of using system transactions -
what ever, depends on your system... (it all has advantages and drawbacks,
you really need to find your strategy for your requirements)
If your "other classes" just do reading you can solve the problem by giving
them a deep isolation level on the reading transaction (eg. read
uncommited).
Now, we might exclusively apply which locking should be applied by the
modification operations. I haven't checked on this and I'm not sure if this
really makes sense since in my opinion it's the transaction reading the data
having to tell wheter it accepts phantom rows, dirty reads etc. and not the
transaction writing the changes telling that an other transaction which has
a high isolation level get's tricked becaues the modifing trans. denies in
appling x-locks when modifing data ... to me that doesn't make to much
sense.
regards
Chris
