Asynchronous ActiveX Replication Problems

Hello,
I have a VB.NET service that has a timer. On certain timer ticks, a
merge replication is called.
I have a wrapper class that asynchronously starts the merge replication
process (using the .BeginInvoke() method). I did this so that my
service could continue to do other things while the merge replication
took place.
Through logging, I know that a separate thread is indeed handling the
replication process.
The problem is that the merge replication appears to block the calling
thread as soon as replication begins. I can see this happening because
I have logging statements inside the merge status event. I see the
calling thread continue to do work until the merge thread begins to
initialize. As soon as the merge is complete, the calling thread once
again continues.
At first I thought that maybe the entire process was blocked by the
merge replication ActiveX object, but the timer event continues to fire.
So it appears that only the calling thread is blocked.
Any ideas?
Thanks,
Jeff
are you using an MSDE database? MSDE is throttled at 8 simultaneous
workloads.
Perhaps this is the problem you are running into.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:Nu02d.286$DY.238@.chiapp18.algx.net...
> Hello,
> I have a VB.NET service that has a timer. On certain timer ticks, a
> merge replication is called.
> I have a wrapper class that asynchronously starts the merge replication
> process (using the .BeginInvoke() method). I did this so that my
> service could continue to do other things while the merge replication
> took place.
> Through logging, I know that a separate thread is indeed handling the
> replication process.
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins. I can see this happening because
> I have logging statements inside the merge status event. I see the
> calling thread continue to do work until the merge thread begins to
> initialize. As soon as the merge is complete, the calling thread once
> again continues.
> At first I thought that maybe the entire process was blocked by the
> merge replication ActiveX object, but the timer event continues to fire.
> So it appears that only the calling thread is blocked.
> Any ideas?
> Thanks,
> Jeff
|||Xref: TK2MSFTNGP08.phx.gbl microsoft.public.sqlserver.replication:56175
Hilary Cotter wrote:
> are you using an MSDE database? MSDE is throttled at 8 simultaneous
> workloads.
No, SQL Server 2000 on both publisher/distributor and subscriber.
But besides that, even if it were being throttled - it shouldn't block
the other thread from continue to process non-SQL Server instructions.
Thanks,
Jeff
|||Can you find out what the merge replication process is doing when it blocks
the other process?
If it is applying a snapshot you can expect blocking. For the type of
singleton transactions that merge replication uses you should not
experieince this level of locking, unless perhaps you are updating columns
which have indexes on them.
You might want to run sp_lock on the client to get an idea of what sort of
locks the replication process is applying.
You might also want to see if perhaps the locking is occuring due to your
code. For instance, I do not experience any locking when using databases
which are part of a merge publication or subscription when the merge
replication agents are running and when I am running the replication process
via tsql or em. This will rule out replication and give you a better window
into what is occuring.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:7b12d.297$DY.106@.chiapp18.algx.net...
> Hilary Cotter wrote:
> No, SQL Server 2000 on both publisher/distributor and subscriber.
> But besides that, even if it were being throttled - it shouldn't block
> the other thread from continue to process non-SQL Server instructions.
> Thanks,
> Jeff
|||Hilary Cotter wrote:
> Can you find out what the merge replication process is doing when it blocks
> the other process?
Yes: It blocks the calling thread as soon as I get the "Initializing"
status until I get the "Complete" status.

> If it is applying a snapshot you can expect blocking. For the type of
> singleton transactions that merge replication uses you should not
> experieince this level of locking, unless perhaps you are updating columns
> which have indexes on them.
> You might want to run sp_lock on the client to get an idea of what sort of
> locks the replication process is applying.
It sounds like you are describing a possible lock on the database. This
is not what is happening. What I am describing is my main thread in my
application is getting blocked until the merge thread (separate from the
main thread) is complete. The main thread is not doing any database
work at all when it gets blocked by the merge thread.

> You might also want to see if perhaps the locking is occuring due to your
> code. For instance, I do not experience any locking when using databases
> which are part of a merge publication or subscription when the merge
> replication agents are running and when I am running the replication process
> via tsql or em. This will rule out replication and give you a better window
> into what is occuring.
I am sure that if I were to run the replication from tsql or em it would
not block - because of my above paragraph. It's the actual ActiveX COM
replication object that is blocking my main thread for some reason. And
like I said in my original post, I am positive that the main thread is
properly spawning a new thread for the merge.
Thanks for the ideas!
Jeff
|||If you want to send the code to me, offline I'll try to repro it.
Otherwise I suggest you open a support incident with PSS.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"Jeff Hedlund" <jeff.hedlund_NOSPAM_@._NOSPAM_elsym.com> wrote in message
news:K%g2d.520$DY.90@.chiapp18.algx.net...[vbcol=seagreen]
> Hilary Cotter wrote:
blocks[vbcol=seagreen]
> Yes: It blocks the calling thread as soon as I get the "Initializing"
> status until I get the "Complete" status.
columns[vbcol=seagreen]
of[vbcol=seagreen]
> It sounds like you are describing a possible lock on the database. This
> is not what is happening. What I am describing is my main thread in my
> application is getting blocked until the merge thread (separate from the
> main thread) is complete. The main thread is not doing any database
> work at all when it gets blocked by the merge thread.
your[vbcol=seagreen]
process[vbcol=seagreen]
window
> I am sure that if I were to run the replication from tsql or em it would
> not block - because of my above paragraph. It's the actual ActiveX COM
> replication object that is blocking my main thread for some reason. And
> like I said in my original post, I am positive that the main thread is
> properly spawning a new thread for the merge.
> Thanks for the ideas!
> Jeff
|||Jeff Hedlund wrote:
> The problem is that the merge replication appears to block the calling
> thread as soon as replication begins.
FYI - I have found the source of my problem. When using BeginInvoke()
to create a separate thread for the replication object, VB.NET uses a
thread from the thread pool.
The thread pool operates with the MTA apartment state. The SQL
replication ActiveX object apparently uses STA, so it was blocking the
MTA apartment while it ran. Make sure I used an STA thread to run the
SQL replication object on solved the blocking problem.
Thanks,
Jeff
sql