1) With your first question there is more going on then stated. For most
scenarios the target is read only (except for Apply) tables (no RI) should
not be locked, so when Apply runs it will take the entire block of work from
the source for the entire SET and "apply" it as a single transaction, with
the idea that upon completion all work at the source (which was at a
consistent point) will be reflected at the target (now also at a consistent
point). BTW, you can use data blocking to break up very large volumes of
work into smaller UOWs.

If however your target is a REPLICA (itself a source), you must define all
RI from the source on the targets, all tables involved in your RI tree need
to be in the same SET, you must run Apply with COMMIT(x). By running with
COMMIT(x), Apply is now transactional and the order and sequence of source
transactions are rebuilt as they occured.

2) If continuous timing you mean SleepMinutes = 0, you should not see Apply
use it's 5 minute sleep. This 5 minute sleep, is an Apply behavior where
after completing it's work, Apply looks at what is next, (either based on
SleepMinutes or Event) Apply decides I have nothing to do for a long time...
however every 5 minutes it opens an eye to check if something has changed.

Hope this helps,

Ray
"soundharya_s" <member8272@dbforums.com> wrote in message
news:2734242.1049587712@dbforums.com...
>
> 1) How do the transactions get applied at the target ... for example,
> when there are two transactions at the source server and the
> transaction 1 updated tables t1 and t2, transaction 2 updates t3 and
> t4 ... And all these tables belong to the same replication
> subscription ... Assume, for some reason t3 is locked, will
> transaction 1 be applied and committed on the target and transaction
> 2 fail at the target as one of the tables is locked ?
>
> 2) What is the continuous timing in Apply config ? Even if I say
> continuous, the changes do not get appled immediately ... The apply
> trace shows it sleeps for 300 seconds
>
> Thanks in Advance for your comments ....
>
>
> Soundh
>
> --
> Posted via http://dbforums.com