I wouldn't be overly concerned about the fact that you are dealing with merge replication. It's a client to SQL Server, just like any other client. It has no more "power" over your SQL Server than any other client process. While there is overview documentation about merge's lineages on msdn, you may need to take a deeper dive by inspecting merge's sprocs. For example, you can USE master EXEC sp_helptext 'SP_MSUPLINEAGEVERSION'.

But before diving in like that (merge's sea is deep), you should consider what you mean by "blocking the database" and "stuck". I think you are talking about blocking in SQL Server, and there is plenty of help about troubleshooting that both here, on msdn, and on many other sites. You may end up discovering your application is blocking merge, and (sometimes), the blocking is happening the other way around :). You may end up discovering the blocking (no matter who is blocking who) is being caused by an "unexpected" physical resource constraint (RAM< IO or CPU). For example, you may be unable to control what else these stores do upon their system. Or, you may discover a logical constraint (an occasional need for a new index). For such concerns, merge and its SP_MSUPLINEAGEVERSION might only be the messenger, not the message :).

Because time is of the essence, you may need to be patient. You may end up acting like blind men feeling different parts of an elephant, where each describes a different beast. You may end up discovering you are donning a pair of peril-sensitive sunglasses, when instead you should have told your patient "This may cause a little pain." You may end up trying to determine the cause of an accident, by only seeing the result. With all that in mind :), you might want to start with sp_lock.