locks on tables...

i have transactional replication with a push, updatable subscriber
configured and
when updates (UPDATEs and DELETEs wrapped in a single transaction) are
executed on the subscriber the changes EVENTUALLY make it back to the
publisher as they should.
the problem i am having is when these sp_MSsync_upd_<tablename> and
sp_MSupd_<tablename> sprocs run on the publisher when the changes occur on
the subscriber they are locking these tables and the entire website (on
publisher side) is unusable due to locks on the records.
but whats weird is that a trace on the publisher that shows all the
sp_MSsync_upd_<tablename> and sp_MSupd_<tablename> calls have SO MANY OF
THEM compared to the actual number of records being deleted on the
subscriber.
Any ideas.
-Terry
Yes, this is one of the problems of using updateable subscribers. Each
singleton in a batch is fired over the network and can cause huge latency
issues, like the one you are seeing. Perhaps you should revisit how you are
doing your replication and select a more appropriate model.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Terry Mulvany" <terry.mulvany@.rouseservices.com> wrote in message
news:OYEe4tnZHHA.3928@.TK2MSFTNGP03.phx.gbl...
>i have transactional replication with a push, updatable subscriber
>configured and
> when updates (UPDATEs and DELETEs wrapped in a single transaction) are
> executed on the subscriber the changes EVENTUALLY make it back to the
> publisher as they should.
> the problem i am having is when these sp_MSsync_upd_<tablename> and
> sp_MSupd_<tablename> sprocs run on the publisher when the changes occur on
> the subscriber they are locking these tables and the entire website (on
> publisher side) is unusable due to locks on the records.
> but whats weird is that a trace on the publisher that shows all the
> sp_MSsync_upd_<tablename> and sp_MSupd_<tablename> calls have SO MANY OF
> THEM compared to the actual number of records being deleted on the
> subscriber.
> Any ideas.
> -Terry
>
>