Merge Replication Conflict Resolution Latency?

I've been having a hard time finding a definitive answer about merge
replication and any sort of latency on a transaction between a
subscriber and publisher. I apologize in advance for the lengthy post,
but it's difficult to really "cut to the meat" of this one
Here's my scenario: I'm developing a .NET CF application on a PocketPC
that stores data in a SQL CE database that merges with a SQL 2000
publisher when the PDA is docked. Generally speaking, what goes up is
properly reflected when it comes back down via a "is complete" row
filter that simply looks for a flag that is set to 1. For example:
-Publisher has 128 rows
-PDA has 128 rows, 28 rows have been "completed"
-Instantiate merge with publisher
-Result is that there are 128 rows on publisher, 28 are complete, row
filter disregards 28 complete records and sends down 100 records that
are still incomplete to PDA
This seems to work great. Now enter conflicts. I have the resolver set
such that the subscriber always wins. We've had several cases where the
server has been under moderate to heavy load, and there have been a lot
of conflicts. This was an actual occurrence:
-Publisher has 79 rows
-PDA has 79 rows, 69 rows have been "completed"
-Publisher had 79 rows *removed*
-Instantiate merge with publisher
-Result is that there are 69 conflicts at publisher, the subscriber wins
all, but there are still *79* rows on the PDA after merge finishes
-I wait a minute and try again, this time there are about 50 rows on the
subscriber
-I repeat this process several times over the course of 5 minutes until
finally, I am left with the correct number of records on the PDA (0)
My question is, is this normal behavior for the resolver? Are conflicts
generally allowed to be "handed off" and the merge allowed to complete
without reflecting their outcome? If so, is there any way to tune or
change this behavior?
This also has me concerned about a normal merge without any conflicts.
Would there ever be a case in which a merge would get out of sync in
this way? My understanding is that instantiating a merge will always
result in both the supplying subscriber and publisher ending up with the
same data at that moment. My merge agents are all using the default
profile.
Thanks a BUNCH for any help you can offer. I've had an impossible time
answering these questions and I'm a programmer before a DBA
-Mike
Mike wrote:

> -Publisher has 79 rows
> -PDA has 79 rows, 69 rows have been "completed"
> -Publisher had 79 rows *removed*
> -Instantiate merge with publisher
> -Result is that there are 69 conflicts at publisher, the subscriber wins
> all, but there are still *79* rows on the PDA after merge finishes
> -I wait a minute and try again, this time there are about 50 rows on the
> subscriber
> -I repeat this process several times over the course of 5 minutes until
> finally, I am left with the correct number of records on the PDA (0)
I apologize, I had my scenarios crossed. This should have read:
-Publisher has 79 rows
-PDA has 79 rows, 69 rows have been "completed"
-Publisher had all 79 rows *modified*
-Instantiate merge with publisher
-Result is that there are 69 conflicts at publisher, the subscriber wins
all and they are noted as resolved in the agent history, but there are
still *79* rows on the PDA after merge finishes
-I wait a minute and try again, this time there are about 50 rows on the
subscriber
-I repeat this process several times over the course of 5 minutes, each
time the number of rows at the subscriber decreases, until finally, I am
left with the correct number of records on the PDA (10)
Thanks
-Mike