I think I'm just not closing or committing something correctly because
it looks like I'm supposed to do something else besides revertChanges to
'clear-out' the previous (failed) request.
I've added this change and it did remove part of the problem. But now
I'm in a sort of limbo. Take for example a deletion of a course subject
using deleteItem().
Previously, I would delete 'Art' which should cause an error. It works
fine and returns the correct error code from the serverside. Then I
would delete 'Science' but it would still be trying to delete 'Art' on
the backend. Using revertChanges() fixed this issue.
However, now I'm getting 2 fault events on the clientside for each
deleteItem() call after the first call. So I can delete 'Art' and
things work great (it shows me the serverside error code when the delete
fails.) But when I try to delete 'Science', it works correctly on the
backend (trying to delete Science and returning the error code), but on
the client side, I get TWO fault events. Oddly enough, the tokens
contained inside both of these FaultEvents have the correct server side
error code ("Cannot delete Science") but the body property of the first
token still has a reference to the 'Art' object, while the second one
has the 'Science' object in the body property. Even more interesting,
from this point on, I will always get 2 faultEvents and no more. It is
not adding a return event for each call, but rather it is treating them
like a stack of 2 with the previous event being removed and the latest
even being added. I always get 2 with the first having the previous
subject value in the body property.
Any ideas?
--- In [email protected], "Jeff Vroom" <[EMAIL PROTECTED]> wrote:
>
> When you get the fault for the first delete, you probably just need to
> call "revertChanges" - either for all changes or just that item.
After
> any fault, all messages you commit as part of that batch get reverted
-
> i.e. put back into the uncommitted list. When you revert them, we'll
> undo those changes - i.e. recreate the deleted item. This is
necessary
> to keep the client's view of the managed state in sync with the
server's
> view.
>
>
>
> Jeff
>
>
>
> ________________________________
>
> From: [email protected] [mailto:[EMAIL PROTECTED]
On
> Behalf Of billy_d_white
> Sent: Monday, February 26, 2007 9:52 AM
> To: [email protected]
> Subject: [flexcoders] FDS with Java Question: Why is it grouping
> requests?
>
>
>
> Maybe Vroom or one of you other FDS experts can tell my what I'm doing
> wrong :
>
> I'm using Cairngorm with a Java/Spring backend. I'm using autocommit
> and autosync enabled and when I perform a deleteItem which I want to
> fail, it calls my Java assembler which attempts the deletion and
> fails. I customize the error message and send it back as a
> MessageException. So far so good.
>
> However, if I then try another deletion, the request is sent to the
> assembler with an array of inside the DataMessage and this array
> contains the previous delete request as well as the new delete
> request. Apparently it is trying to batch the multiple requests since
> the previous one failed. (These are stored in that _token_chain_
> property of the request) How do I avoid this and make each deletion
> request atomic so it will not attempt to execute the previous (failed)
> request? Do I need to re-write the service call on the client to use
> the manual commit() call or something like that?
>
> Any
>
