All

Did anyone else here experience something "strange" with the AfterCommit event? I did not see it until today when I was debugging my ISAPI dll for a commit request. In the EWB App I set the below code for every Commit request i fire as I need to take some action after each commit or commit error. However, when I click the button to commit some data, the AfterCommit procedure that I declared is immediately called. In Delphi, the cursor just stopped at my break-point so the commit request is not completed at the server. Once I complete debugging and send a successful / 200 code back, nothing happen in EWB2. If, however, an error occur, that event in EWB2 is not fired until I finish debug and the result are returned.

     With Database do begin
        Params.Clear;
        BaseURL := 'isapi/txp_candidate_appraisal.dll/commit';
        AfterCommit := AfterCommitSave;
        OnCommitError := CommitErrorSave;
        Params.Add('AppID=' + Trim(frmMain.AppID));
        Params.Add('AppGUID=' + Trim(frmMain.AppGUID));
        Commit;
     end;

Can't really recall if this was the case with EWB1.x, but I guess I'll have to test it there as well

Best regards

Eivind

Eivind,

<< Did anyone else here experience something "strange" with the AfterCommit
event? I did not see it until today when I was debugging my ISAPI dll for a
commit request. In the EWB App I set the below code for every Commit request
i fire as I need to take some action after each commit or commit error.
However, when I click the button to commit some data, the AfterCommit
procedure that I declared is immediately called. In Delphi, the cursor just
stopped at my break-point so the commit request is not completed at the
server. Once I complete debugging and send a successful / 200 code back,
nothing happen in EWB2. If, however, an error occur, that event in EWB2 is
not fired until I finish debug and the result are returned. >>

EWB 2 introduces the concept of pending commits:

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Transactions

Commits are now fully asynchronous in EWB, especially in terms of when the
AfterCommit is fired relative to whether the commit actually succeeded or
not.  This was done to allow for using transaction wrappers around
data-bound control actions (BeforeUpdate, AfterUpdate, etc.).  In EWB 1.x,
you couldn't do this without running into timing issues with the events
because the transaction commits were asynchronous server requests, but *not*
asynchronous with respect to the AfterCommit event and how the transactions
were handled at the TDatabase level.

So, now you can call Commit and the transaction will appear committed on the
EWB side immediately.  If there are any issues with the Commit, you'll
receive an asynchronous OnCommitError event trigger, and you can use the
TDatabase.RetryCommit method to retry *any* pending commits.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

so what is the right way to display a message to the user if the commit was successful ?

Uli

On 5/15/2015 3:09 PM, Uli Becker wrote:
> so what is the right way to display a message to the user if the commit was successful ?

Checking if PendingCommits = 0 should work and also allows to retry as
well. It is bit extra work though.

Raul

Raul,

> Checking if PendingCommits = 0 should work and also allows to retry as
> well. It is bit extra work though.

Thanks. Since it's asynchronous, I guess I need a Timer for that?

Uli

Hmmm, ok. Not my perfect way of doing though. Much more like to have a procedure called when the commit is successful. My whole app structure depends on it.

So, the PendingCommits stay higher than 0 until the server reports a successful completion? In that case, EWB2 has to receive some kind of call back call when this happens and set the PendingCommits back to 0? If that is the case, can we plug into and listen for that callback function and create our own "AfterCommit"? (Please say yes )

Thanks

Eivind



Uli Becker wrote:

Raul,

> Checking if PendingCommits = 0 should work and also allows to retry as
> well. It is bit extra work though.

Thanks. Since it's asynchronous, I guess I need a Timer for that?

Uli

If we are voting - I would like (need) this event to.

There may be other related database activities predicated on the completion and setting a timer when a response is coming back doesn't make sense.

Walter

On 5/16/2015 2:05 AM, Uli Becker wrote:
> Thanks. Since it's asynchronous, I guess I need a Timer for that?

That's how i see it at this time. Timer to check until pending commits
is 0 and the cancel timer once done.

Raul

On 5/16/2015 10:52 AM, Eivind wrote:
> Hmmm, ok. Not my perfect way of doing though. Much more like to have a procedure called when the commit is successful. My whole app structure depends on it.
> So, the PendingCommits stay higher than 0 until the server reports a successful completion? In that case, EWB2 has to receive some kind of call back call when this happens and set the PendingCommits back to 0? If that is the case, can we plug into and listen for that callback function and create our own "AfterCommit"? (Please say yes )


There are few things at play - the pending and retry capability makes
the client side code lot easier to deal with in ewb2 (since it handle
multiple of these and not just 1 pending commit).

You will get OnCommitError if anything fails and can get decide if you
should RetryCommit etc.

Hence not receiving this would be indication that it succeeded but again
due to async timings one does not know when it took place actually.

Event when actual commit succeeded would be useful.

Looking at the code TDatabase.RequestComplete is getting called after
request completes which in turn calles EndCommit - this itself will
continue to send pending commit so it would be straightforward to add
"OnAllCommitsComplete" event call here. However if you want 1 call per
commit (i.e. you need to know which commit completed) then that might
need bit more work.

Raul

The Event - even if nested - means we could check the PendingCommits in the event and make a decision.at that time.  So if you are not doing nested Transactions it would be equivalent to EWB 1 behaviour.

Walter