[flexcoders] Re: How to 'undo' the changes in the flex client w/ LCDS when a rollback is isssued?
I would totally see it as a bug. If LCDS manages the object, it is its role to
propagate up the rollback. No question about it.
Good luck in your new adventure, whatever it is!
Thanks.
--- In flexcoders@yahoogroups.com, Jeffrey Vroom j...@... wrote:
In my opinion, LCDS should detect that you've called setRollbackOnly and
deliver a generic fault to the client. I just recently left Adobe so it is
not my position anymore to say for sure it is a bug or just the way it
works. I vaguely recall a bug opened on this issue but can't check since
that bug system is not public.
Jeff
On Wed, Apr 29, 2009 at 12:09 PM, Mehdi elextra...@... wrote:
--- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, Jeffrey
Vroom jeff@ wrote:
I think this is a bug - calling setRollbackOnly does not trigger the
fault
handler. The server knows that transaction failed but the client does not
so things get out of sync. You have to throw an exception from your
assembler methods to get the fault handler called. When you do that, if
use-transactions=true, the rollback will happen automatically. this also
gives you the ability to pass the message of your exception to the client
so
your fault handler knows what exactly the error was on the server.
At that point, you can call revertChanges to undo that change.
Jeff
On Wed, Apr 29, 2009 at 9:15 AM, Mehdi elextraana@ wrote:
The typical example.
You have a datagrid that is bound with an arraycollection, which source
is
managed by LCDS via ds.fill().
your datagrid is editable. The user edits a value in the collection and
you
fire a commit. (ds.commit()).
Let say you are using a custom assembler. The
updateItem(newVersion,prevVersion,changesList) method will be invoked.
There assuming something goes wrong and you call:
DataServiceTransaction.getCurrentDataServiceTransaction().setRollbackOnly();
I can see the db rolling back no problem. But my client did not get any
notification!
I have callback functions in the commit, and I have event listener on
the
ds (fault and result) AS such:
_dataService.commit();
token.addResponder(new AsyncResponder(
function onAsyncResult(result:Object, token:Object = null) : void
{
}
function onAsyncFault(.../...)
)
AND,
_dataService.addEventListener(DataServiceFaultEvent.FAULT,
this.onFault,
false, 0, true);
_dataService.addEventListener(ResultEvent.RESULT, this.onResult, false,
0,
true);
NONE of these callbacks get called. So I basically have no way of
knowing
that a rollback happened, and the user datagrid is still showing the
wrong
value, since the commit failed. Any idea?
Note that however when an exception is thrown on the server
(updateItem()
method), I do indeed get a callback via the AsyncFault method.
Thank you.
Hi Jeff,
I'm not sure what you meant by:
I think this is a bug - calling setRollbackOnly does not trigger the fault
handler
Are you confirming the fact that this is a bug, and that calling
setRollbackOnly SHOULD actually call the fault handler or you are saying
that only throwing an exception should do it.?
thanks.
[flexcoders] Re: How to 'undo' the changes in the flex client w/ LCDS when a rollback is isssued?
--- In flexcoders@yahoogroups.com, Jeffrey Vroom j...@... wrote:
I think this is a bug - calling setRollbackOnly does not trigger the fault
handler. The server knows that transaction failed but the client does not
so things get out of sync. You have to throw an exception from your
assembler methods to get the fault handler called. When you do that, if
use-transactions=true, the rollback will happen automatically. this also
gives you the ability to pass the message of your exception to the client so
your fault handler knows what exactly the error was on the server.
At that point, you can call revertChanges to undo that change.
Jeff
On Wed, Apr 29, 2009 at 9:15 AM, Mehdi elextra...@... wrote:
The typical example.
You have a datagrid that is bound with an arraycollection, which source is
managed by LCDS via ds.fill().
your datagrid is editable. The user edits a value in the collection and you
fire a commit. (ds.commit()).
Let say you are using a custom assembler. The
updateItem(newVersion,prevVersion,changesList) method will be invoked.
There assuming something goes wrong and you call:
DataServiceTransaction.getCurrentDataServiceTransaction().setRollbackOnly();
I can see the db rolling back no problem. But my client did not get any
notification!
I have callback functions in the commit, and I have event listener on the
ds (fault and result) AS such:
_dataService.commit();
token.addResponder(new AsyncResponder(
function onAsyncResult(result:Object, token:Object = null) : void
{
}
function onAsyncFault(.../...)
)
AND,
_dataService.addEventListener(DataServiceFaultEvent.FAULT, this.onFault,
false, 0, true);
_dataService.addEventListener(ResultEvent.RESULT, this.onResult, false, 0,
true);
NONE of these callbacks get called. So I basically have no way of knowing
that a rollback happened, and the user datagrid is still showing the wrong
value, since the commit failed. Any idea?
Note that however when an exception is thrown on the server (updateItem()
method), I do indeed get a callback via the AsyncFault method.
Thank you.
Hi Jeff,
I'm not sure what you meant by:
I think this is a bug - calling setRollbackOnly does not trigger the fault
handler
Are you confirming the fact that this is a bug, and that calling
setRollbackOnly SHOULD actually call the fault handler or you are saying that
only throwing an exception should do it.?
thanks.
Re: [flexcoders] Re: How to 'undo' the changes in the flex client w/ LCDS when a rollback is isssued?
In my opinion, LCDS should detect that you've called setRollbackOnly and
deliver a generic fault to the client. I just recently left Adobe so it is
not my position anymore to say for sure it is a bug or just the way it
works. I vaguely recall a bug opened on this issue but can't check since
that bug system is not public.
Jeff
On Wed, Apr 29, 2009 at 12:09 PM, Mehdi elextra...@yahoo.ca wrote:
--- In flexcoders@yahoogroups.com flexcoders%40yahoogroups.com, Jeffrey
Vroom j...@... wrote:
I think this is a bug - calling setRollbackOnly does not trigger the
fault
handler. The server knows that transaction failed but the client does not
so things get out of sync. You have to throw an exception from your
assembler methods to get the fault handler called. When you do that, if
use-transactions=true, the rollback will happen automatically. this also
gives you the ability to pass the message of your exception to the client
so
your fault handler knows what exactly the error was on the server.
At that point, you can call revertChanges to undo that change.
Jeff
On Wed, Apr 29, 2009 at 9:15 AM, Mehdi elextra...@... wrote:
The typical example.
You have a datagrid that is bound with an arraycollection, which source
is
managed by LCDS via ds.fill().
your datagrid is editable. The user edits a value in the collection and
you
fire a commit. (ds.commit()).
Let say you are using a custom assembler. The
updateItem(newVersion,prevVersion,changesList) method will be invoked.
There assuming something goes wrong and you call:
DataServiceTransaction.getCurrentDataServiceTransaction().setRollbackOnly();
I can see the db rolling back no problem. But my client did not get any
notification!
I have callback functions in the commit, and I have event listener on
the
ds (fault and result) AS such:
_dataService.commit();
token.addResponder(new AsyncResponder(
function onAsyncResult(result:Object, token:Object = null) : void
{
}
function onAsyncFault(.../...)
)
AND,
_dataService.addEventListener(DataServiceFaultEvent.FAULT,
this.onFault,
false, 0, true);
_dataService.addEventListener(ResultEvent.RESULT, this.onResult, false,
0,
true);
NONE of these callbacks get called. So I basically have no way of
knowing
that a rollback happened, and the user datagrid is still showing the
wrong
value, since the commit failed. Any idea?
Note that however when an exception is thrown on the server
(updateItem()
method), I do indeed get a callback via the AsyncFault method.
Thank you.
Hi Jeff,
I'm not sure what you meant by:
I think this is a bug - calling setRollbackOnly does not trigger the fault
handler
Are you confirming the fact that this is a bug, and that calling
setRollbackOnly SHOULD actually call the fault handler or you are saying
that only throwing an exception should do it.?
thanks.
