Mahadev, Thanks for the reply, I appreciate it. This information is super helpful.
Yes, the multi is stored in one txn. Great suggestion regarding jira... I'll summarize this email chain on jira later today. Thanks, Marshall ----- Original Message ----- > Marshall, > I am assuming that the new multi update is actually a single txn. > What you > need to do next it make sure you take a look at all the processors. > > Sync is one where this new txn will need to be logged and then Final > is one > where the Datatree needs to be updated to reflect all the updates. > > Its better to keep the discusson on the jira so that any else > interested can > look at it as well (also for record sake)! > > Thanks > mahadev > > > On 4/21/11 9:42 AM, "Ted Dunning" <[email protected]> wrote: > > > I am adding the dev list. > > > > Mahadev, > > > > Can you help with a pointer here? > > > > On Thu, Apr 21, 2011 at 9:15 AM, Marshall McMullen > > <[email protected]> wrote: > >> I've finished the necessary work inside PrepRequestProcessor.java > >> to deal > >> with multi-ops. Where is the next layer of this that I need to > >> start working > >> on? I'm guessing it's perhaps in one of SyncRequestProcessor, > >> FinalRequestProcessor, ZKDatabase or DataTree ? I'll start looking > >> around > >> but any guidance is appreciated. > >> Thanks!! > >> > >> ________________________________ > >> > >> Yep, I discovered that vital piece of info after I emailed this > >> out earlier. > >> Glad to see I'm on the right track :-). > >> > >> ________________________________ > >> > >> I think you'll need to validate against the changerecord info as > >> well. Call > >> getRecordForPath after you've added a changerecord for the create > >> command. > >> Assuming like ted said ordering is maintained, which it should be. > >> Is that > >> not working? > >> > >> C > >> > >> On Apr 20, 2011 4:50 PM, "Marshall McMullen" > >> <[email protected]> wrote: > >>> I've been pursuing Camille's suggestion of modifying > >>> PrepRequestProcessor > >>> to validate all of the ops inside the MultiTransactionRecord. It > >>> essentially > >>> calls pRequest to ensure validity of the given request. It works > >>> perfectly > >>> on simple cases that don't depend on other ops within the multi > >>> transaction > >>> having already been committed. For example, if you have an empty > >>> database > >>> and submit a multi transaction that contains: > >>> > >>> create "foo" ... > >>> delete "foo" ... > >>> > >>> Then the validation of the delete on "foo" fails as that op > >>> hasn't been > >>> committed yet. > >>> > >>> I'm missing something important here.... anyone want to offer > >>> some > >>> guidance on how this should be handled? > >>> > >>> Thanks very much, > >>> Marshall > >>> > >>> ----- Original Message ----- > >>> > >>>> I would start in preprequestprocessor. Add a case for multi-resp > >>>> and > >>>> validate all of the ops contained therein. > >>>> Will look more tonight to flesh out other steps, but that should > >>>> hopefully be enough to start. Be sure to think about unit > >>>> testing > >>>> this... we don't seem to have one for prequest at the moment but > >>>> it > >>>> seems totally doable to me. > >>>> C > >>> > >>>> On Apr 19, 2011 1:58 PM, "Marshall McMullen" < > >>>> [email protected] > >>>>> wrote: > >> > >> > >> > > > >
