Sunday, November 28, 2010

Re: RequestFactory - A request is already in progress

Problem solved...
I was confused about two key points (sadly confusion is an
occupational hazard for us morons):
1) When to "reuse" a RequestContext vs. creating a new RequestContext
2) What Objectify.put() actually does

For #1, I believe that the same dynatablerf code put it as "using the
given RequestContext to accumulate the edits." My usage had been
somewhat random prior to that. So, when calling the persist() I now
made sure to use the right RequestContext.

For #2, I had been making the change to the Commitment, then calling
put() and then making a change to the CommitUser, and then calling
put() again. Now I make the changes to both entities and call put()
once. This seemed to be the more important of the two.

These items may be obvious to all others, but on the off-chance there
are other old folks trying to write code....

Enjoy,
RB

On Nov 28, 2:04 pm, Richard Berger <richardlan...@gmail.com> wrote:
> Similar problem, but I was not able to implement your solution - any
> guidance is suggested.  And I promise, once I get my simple app
> working, I will write the "GWT/Objectify 1-to-Many Relationships for
> Moron Like Me" guide :).
>
> The problem in the small...
> CommitUsers can have Commitments.  I create a new Commitment and try
> to associate that with the CommitUser.  But the properties on the
> CommitUser (even just a string) are not persisted.  So, following:http://code.google.com/webtoolkit/doc/latest/DevGuideRequestFactory.h...
> in the section on Using RequestFactory, I figure I must be falling
> into the trap of not having an editable CommitUser (since I didn't
> create it, the CommitUseralreadyexists).
>
> So I change my code from:
>  Request<Void> createReq =
> commitmentRequest.persist(currentCommitUserProxy).using(newCommitment);
>
> To:
>   CommitUserProxy editableCommitUserProxy =
> commitUserReq.edit(currentCommitUserProxy);
>  Request<Void> createReq =
> commitmentRequest.persist(editableCommitUserProxy).using(newCommitment);
>
> Where:
>   commitUserReq is:
>         private CommitUserRequest commitUserReq =
> requestFactory.commitUserRequest();
>  requestFactory is:
>         CommitmentSystemRequestFactory requestFactory =
> GWT.create(CommitmentSystemRequestFactory.class);
>
> This gives me the error:
> Caused by: java.lang.IllegalStateException: Arequestisalreadyinprogress
>     at
> com.google.gwt.requestfactory.client.impl.AbstractRequestContext.checkLocke d(AbstractRequestContext.java:
> 307)
>
> Following the advice you provided, I tried to create a new
> RequestContext, so my code became...
>   CommitUserRequest commitUserReq2 =
> requestFactory.commitUserRequest();
>   CommitUserProxy editableCommitUserProxy =
> commitUserReq2.edit(currentCommitUserProxy);
>  Request<Void> createReq =
> commitmentRequest.persist(editableCommitUserProxy).using(newCommitment);
> But that gave me the error:
>
> Caused by: java.lang.IllegalArgumentException: Attempting to edit an
> EntityProxy previously edited by another RequestContext
>   at
> com.google.gwt.requestfactory.client.impl.AbstractRequestContext.checkStrea msNotCrossed(AbstractRequestContext.java:
> 334)
>
> Stepping back a little bit, the slightly bigger picture is that I am
> following the article at:http://www.ibm.com/developerworks/java/library/j-javadev2-13/index.html
> (Java development 2.0: Twitter mining with Objectify-Appengine, Part
> 1).  But that article doesn't use GWT.  But the idea is that the
> Commitment stores a Key<CommitUser> so that I can query the
> Commitment.class to find all the Commitments whose Key matches the Key
> of the current user.  When I save a Commitment, I first save the
> Commitment itself and then establish the relationship by modifying the
> CommitUser (as the article demonstrates).  So, my persist method
> (fired above) is...
>
>   public void persist(CommitUser commitUser) {
>     // Save commitment first
>     DAO dao = new DAO();
>     Objectify ofy = dao.ofy();
>     ofy.put(this);
>     dao = null;
>     // Then establish relationship
>     commitUser.addCommitment(this);  // Owner is in charge
>   }
>
> And the addCommitment method on the CommitUser is:
>   public  void addCommitment(Commitment commitment) {
>     DAO dao = new DAO();
>     Objectify ofy = dao.ofy();
>     commitment.setRequesterKey(this);
>     commitment.setDescription("Updated in addCommitment");
>     ofy.put(this);
>     dao = null;
>   }
>
> And finally, the commitment.setRequestKey() is:
>   public void setRequesterKey(CommitUser commitUser) {
>     this.requesterKey = new Key<CommitUser>(CommitUser.class,
> commitUser.getId());
>   }
>
> In the debugger I can see that all the properties - e.g. "Description"
> get set, but they are not persisted to the Datastore.
>
> I am sure this is common, but it seems that I am very close to getting
> this simple example to work - so any assistance is greatly appreciated
> and I will do my best to provide assistance to the community.  I think
> my qualifications as a moron have to be helpful in some way.  I am
> also old if that helps :) :).
>
> Thanks all!
> RB
>
> On Nov 9, 7:01 am, Ramon Buckland <ra...@thebuckland.com> wrote:
>
>
>
>
>
>
>
> > Thanks Tobias,
>
> > That explanation was good. I had it right logically, but omitted
> > calling one of my "special - create me a new " methods, that replaced
> > my RequestContext for me.
>
> > All good niow. it saves data!
>
> > On Nov 9, 2:28 pm, Tobias <thaberm...@gmail.com> wrote:
>
> > > I *think* that happens after you have fired a RequestContext. From
> > > looking at the code, which is a bit hard because of the
> > > DeferredBinding that's going on there, the "locked" variable in a
> > > RequestContext gets only reset to "false", if the firedRequestfails.
> > > So I think you need to use a new RequestContext.
>
> > > Regards,
> > > Tobias
>
> > > On Nov 9, 12:48 pm, Ramon Buckland <ra...@thebuckland.com> wrote:
>
> > > > Hi All,
>
> > > > I am currently in the process of building an app, initally based off
> > > > the Roo framework.
> > > > I am getting a "Arequestisalreadyinprogress" at the point where I
> > > > call create for a child entity.
>
> > > > Is there a way I can see what "requestcontexts" are inprogress, so I
> > > > can debug where my logic is off ??
> > > > Either using firebug or the eclipse debugger.
>
> > > > The stack trace I get is
>
> > > >Causedby:java.lang.IllegalStateException: Arequestisalreadyin
> > > >progress
> > > >         at
> > > > com.google.gwt.requestfactory.client.impl.AbstractRequestContext.checkLocke d(AbstractRequestContext.java:
> > > > 307)
> > > >         at
> > > > com.google.gwt.requestfactory.client.impl.AbstractRequestContext.create(Abs tractRequestContext.java:
> > > > 76)
> > > >         at
> > > > isupro.client.scaffold.businessprocess.ui.AbstractBusinessProcessActivity.c reateNewObjectiveProxy(AbstractBusinessProcessActivity.java:
> > > > 92)
>
> > > > My method (createNewObjectiveProxy()) usese the existingrequest,
> > > > created prior so that this "new" object is in the same context.
>
> > > >     public ObjectiveProxy createNewObjectiveProxy() {
> > > >         ObjectiveProxy obj =
> > > > getRequest().create(ObjectiveProxy.class);
> > > >         obj.setId(editableBP.getId());
> > > >         editableBP.getObjectives().add(obj);
> > > >         return obj;
> > > >     }
>
> > > > Now, without looking at my code, it will be hard for anyone to assist
> > > > I assume, which is why I ask " how do I go about working out where my
> > > > problem is"
>
> > > > regards
> > > > Ramon

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

No comments:

Post a Comment