Not sure I follow your exact meaning but the snapshot isn't retaken on every read operation for a transaction. After opening a transaction, the first read operation to a shard will take the snapshot and read from it The second read operation to that shard will also read from it. If you open another transaction, that will take another snapshot.
On Thu, Sep 15, 2016 at 10:57 AM, Sela, Guy <guy.s...@hpe.com> wrote: > Understood, so this means there is no way to get a snapshot of the entire > MD-SAL state, even in a single instance deployment, because the snapshot is > *retaken* on every read operation. Correct? > > > > *From:* Tom Pantelis [mailto:tompante...@gmail.com] > *Sent:* Thursday, September 15, 2016 4:29 PM > *To:* Sela, Guy <guy.s...@hpe.com> > *Cc:* Muthukumaran K <muthukumara...@ericsson.com>; Moiz Raja (moraja) < > mor...@cisco.com>; Srini Seetharaman <srini.seethara...@gmail.com>; > controller-dev <controller-dev@lists.opendaylight.org> > > *Subject:* Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > I assume DataTree X and Y are in different shards. The snapshot of > the DataTree in a backend shard is actually taken at the time of the first > operation (read, write etc) referencing a path for that shard. Since > the newXXXTransaction methods provide no path context, capturing > the snapshot at the time of the newXXXTransaction call would entail > creating a transaction/snapshot in every shard which would not > be efficient. > > > > I think the new DataTreeProducer APIs are designed to overcome this b/c > you specify the path on creation of the DataTreeProducer so it knows up > front which backend shards will be accessed. > > > > On Thu, Sep 15, 2016 at 8:26 AM, Sela, Guy <guy.s...@hpe.com> wrote: > > Hi, > > This question and answers raised another question in my head. > > Today when calling DataBroker.newReadTransaction() we are supposed to get > a snaphost of the complete data tree. > > If we are running in a cluster, it means that some shard aren’t led by the > current instance. > > How can the snapshost work? > > > > Let’s say I have 2 instances in the Cluster – ODL X and ODL Y. > > And I have 2 data trees – DataTree X and DataTree Y. Both reside in the > configuration data store. > > > > In ODL X I call DataBroker.newReadTransaction(). > > Up until now I thought it does some kind of a reference to the data in all > MD-SAL, and use some kind of “copy on write”, to handle modifications. > > Now, since I read that the reads are actually invoked in the Leader > instance, I understand this can’t be the case. > > > > If I’ll take the transaction object and do two reads, first read from > DataTree X and second read from DataTree Y, will they be of the same > snapshot? The snapshot that was “created” at the time I called > newReadTransaction()? > > > > > > *From:* controller-dev-boun...@lists.opendaylight.org [mailto: > controller-dev-boun...@lists.opendaylight.org] *On Behalf Of *Muthukumaran > K > *Sent:* Thursday, September 15, 2016 7:29 AM > *To:* Moiz Raja (moraja) <mor...@cisco.com>; Tom Pantelis < > tompante...@gmail.com>; Srini Seetharaman <srini.seethara...@gmail.com> > *Cc:* controller-dev <controller-dev@lists.opendaylight.org> > > > *Subject:* Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > Hi Srini, > > > > We have tried the approach what Moiz had mentioned – using CDTCN and > caching data, and it was quite performant in one of our reference > application. You may want to look - https://git.opendaylight.org/ > gerrit/#/c/45131/ > > > > Regards > > Muthu > > > > > > > > *From:* controller-dev-boun...@lists.opendaylight.org [ > mailto:controller-dev-boun...@lists.opendaylight.org > <controller-dev-boun...@lists.opendaylight.org>] *On Behalf Of *Moiz Raja > (moraja) > *Sent:* Thursday, September 15, 2016 3:06 AM > *To:* Tom Pantelis; Srini Seetharaman > *Cc:* controller-dev > *Subject:* Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > The single use ClusteredDataChange/ClusteredDataTreeChange listeners are > fine and may perform better than the remote read but if you really have a > lot of reads even this mechanism is expensive as there is quite a bit of > overhead associated with setting up a listener. > > > > I would recommend that you setup a ClusteredDataTreeChangeListener (for > long term use) for the data that you want to constantly read and cache the > data in that listener. Then provide a way to read from that cache. > > > > -Moiz > > > > *From: *Tom Pantelis <tompante...@gmail.com> > *Date: *Wednesday, September 14, 2016 at 2:26 PM > *To: *Srini Seetharaman <srini.seethara...@gmail.com> > *Cc: *Moiz Raja <mor...@cisco.com>, controller-dev <controller-dev@lists. > opendaylight.org> > *Subject: *Re: [controller-dev] [documentation] Questions about ODL > clustering > > > > All reads still go to the leader. There has been an enhancement > https://bugs.opendaylight.org/show_bug.cgi?id=2504 open for this but > hasn't been implemented. There is an alternative way using > a DataTreeChangeListener as Moiz mentioned in the bug. > > > > On Wed, Sep 14, 2016 at 4:57 PM, Srini Seetharaman < > srini.seethara...@gmail.com> wrote: > > With Beryllium-SR3, I just verified using tcpdump on port 2550 that the > data for the read operation at the follower came over the network from the > shard leader. > > > > Is there any plan with Boron to make it a local read from the replica? > > > > On Wed, Sep 14, 2016 at 1:43 PM, Srini Seetharaman < > srini.seethara...@gmail.com> wrote: > > Hi Tom and Moiz > > Is it still the case with Beryllium and Boron that the read transactions > from a follower are forwarded to the leader? > > > > Thanks > > Srini. > > > > On Sat, Feb 28, 2015 at 8:26 AM, Tom Pantelis <tompante...@gmail.com> > wrote: > > Colin, Tianzhu > > > > Reads are also forwarded to the leader so, yes, remote reads would take > longer. With IMDS, reads are actually synchronous so the returned Future is > immediate but with CDS, the read is async, whether it's local or not. So > it's best to not block on the Future as there will be some latency with > CDS, but rather use a Future callback if possible. > > > > Tom > > > > On Sat, Feb 28, 2015 at 10:42 AM, Colin Dixon <co...@colindixon.com> > wrote: > > I'm cc'ing controller-dev since they will have the authoritative answer. > > I *think* the answer is that all data is replicated to all nodes in the > cluster and so all reads can be local. Only writes have to go to the shard > leader, but I could be wrong. > > Moiz and Tom Pantelis would know more. > > > > --Colin > > > > On Sat, Feb 28, 2015 at 4:55 AM, 我心永恒 <zhuzhuaiqiqi1...@gmail.com> wrote: > > Dear all, I am studying ODL and have one question: > > > > When a consumer launches a read transaction, if I'm not wrong, it has to > be forwarded to the primary shard controller. So if this case is possible > that the transaction is remote and the consumer has to wait longer since > the transaction is not local? > > > > Thanks & regards > > Tianzhu > > > > > _______________________________________________ > documentation mailing list > documentat...@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/documentation > > > > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > > > > _______________________________________________ > controller-dev mailing list > controller-dev@lists.opendaylight.org > https://lists.opendaylight.org/mailman/listinfo/controller-dev > > > > > > > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
