Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 92252 invoked from network); 23 Nov 2008 19:37:57 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 23 Nov 2008 19:37:57 -0000 Received: (qmail 5437 invoked by uid 500); 23 Nov 2008 19:38:07 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 5272 invoked by uid 500); 23 Nov 2008 19:38:07 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 5261 invoked by uid 99); 23 Nov 2008 19:38:07 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Nov 2008 11:38:07 -0800 X-ASF-Spam-Status: No, hits=-0.3 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (athena.apache.org: transitioning domain of fern@alum.mit.edu does not designate 66.111.4.25 as permitted sender) Received: from [66.111.4.25] (HELO out1.smtp.messagingengine.com) (66.111.4.25) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 23 Nov 2008 19:36:41 +0000 Received: from compute2.internal (compute2.internal [10.202.2.42]) by out1.messagingengine.com (Postfix) with ESMTP id 9F3C81C2958 for ; Sun, 23 Nov 2008 14:37:26 -0500 (EST) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute2.internal (MEProxy); Sun, 23 Nov 2008 14:37:26 -0500 X-Sasl-enc: g5WQrawDahUqV+YaWAZ8LWnQF3WUfky+MZjkGP1q9zSC 1227469046 Received: from protrade-users-powerbook-g4-15.local (adsl-69-228-227-106.dsl.pltn13.pacbell.net [69.228.227.106]) by mail.messagingengine.com (Postfix) with ESMTPSA id E67183106F for ; Sun, 23 Nov 2008 14:37:25 -0500 (EST) Message-ID: <4929B0F6.1060106@alum.mit.edu> Date: Sun, 23 Nov 2008 11:37:26 -0800 From: Fernando Padilla User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: dev@openjpa.apache.org Subject: Re: slices, persist? References: <49275024.5040808@alum.mit.edu> <1227468298736-1569365.post@n2.nabble.com> In-Reply-To: <1227468298736-1569365.post@n2.nabble.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Cool thank you. The code is just complicated, I just need to wrap my head around the Broker code some more. I got confused because I imagined that an "operation" would match a transaction. But reviewing more code, and your response, it looks like an "operation" just maps to one single call of the broker, no matter how many calls are done within one transaction. I guess demarcating an operation within a transaction is there to track all of the side-effects of an operation.. just like when you persist one object, but the system actually persists many objects as a side effect.. thanx Pinaki Poddar wrote: > Not sure if this forum is the correct place for education on how (or why) a > specific code block works (or does not;). However, the following cited > inference very weird you should say this.. > > "it seems like within one DistributedBrokerImpl, you can only persist > against one slice" > > is not true. > > What the code body realizes is: > Every instance X that is an explicit argument of EntityManager.persist() and > the set of instanes {Y} that are reachable directly or indirectly from X at > the time of persist() call will be stored in Slice A where A designates that > slice as returned by DistributionPolicy.distribute(X). > > So if we consider to calls in the same transaction > EntityManager.persist(X1); > EntityManager.persist(X2); > and DistributionPolicy.distribute(X1) and DistributionPolicy.distribute(X2) > return different Slices then X1 and X2 will be stored in different slices. > > > > Fernando Padilla wrote: >> Still reviewing code :) >> >> So I'm looking over this, and it seems like within one >> DistributedBrokerImpl, you can only persist against one slice. Since >> the _rootSlice is set on the very first object that it tries to persist, >> and never again. >> >> So I'm new here, so I am assuming that one Broker is used per >> EntityManager, but what if I want to use one EntityManager to persist >> two kinds of objects that live in different slices.. am I just reading >> this wrong? >> >> The persist would be called on object A, the the persist would be called >> on object B, but it would use the rootSlice determined by A? >> >> Or is a broker used once per transaction. But even then I might want to >> create an object A and object B within the same "transaction". >> >> please help. >> >> >> >> /** >> * Assigns slice identifier to the resultant StateManager as initialized >> by >> * the super class implementation. The slice identifier is decided by >> * {@link DistributionPolicy} for given pc if it is a root >> * instance i.e. the argument of the user application's persist() call. >> The >> * cascaded instances are detected by non-empty status of the current >> * operating set. The slice is assigned only if a StateManager has never >> * been assigned before. >> */ >> @Override >> public OpenJPAStateManager persist(Object pc, Object id, boolean >> explicit, >> OpCallbacks call) { >> OpenJPAStateManager sm = getStateManager(pc); >> String[] targets = null; >> boolean replicated = SliceImplHelper.isReplicated(sm); >> if (getOperatingSet().isEmpty() >> && (sm == null || sm.getImplData() == null)) { >> targets = SliceImplHelper.getSlicesByPolicy(pc, getConfiguration(), >> this); >> if (!replicated) { >> _rootSlice = targets[0]; >> } >> } >> sm = super.persist(pc, id, explicit, call); >> if (sm.getImplData() == null) { >> if (targets == null) { >> targets = replicated >> ? SliceImplHelper.getSlicesByPolicy(pc, getConfiguration(), this) >> : new String[]{_rootSlice}; >> } >> sm.setImplData(targets, true); >> } >> return sm; >> } >> >> >