<<
Walter Matte wrote:

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.
>>

It depends what you want the event to be - if it's the final event (i.e. all commits done) then pending commits will always be 0. This also ties into the current EWB2 logic where all of the events are batched together - you retry all (not just single one) and once they start working they all get sent one after another.

If you want the event to be per commit then you can check pending but should not do retries yourself since framework is already sending pending event for you (OnCommitError is where you should cancel anything you don't need or want and call retries).

Hence the event should be strictly to decide how your app is behaving (i.e. maybe you have a progress dialog that gets hidden once all are done or maybe you don't reload UI until all commits are known to be completed).

If you have 1 commit event only then of course the 2 scenarios are the same.

Nested is same as before - the "real" commit does not get triggered until you trigger the outermost/last commit (i.e. transactionlevel = 0).

Anyways, let's see what Tim says.

Raul

Raul,

> If you want the event to be per commit then you can check... (OnCommitError is where you should cancel anything you don't need or want and call retries)

Assumed I have enabled a timer which checks PendingCommits and the
commit is never successful, does PendingCommits stay at a value > 0?
If I want to use a "TimeOut": how can I cancel a pending commit?

The most common scenario would be:

1. The user enters a new record and clicks on "Save"
2. Commit is sucessful and the user get a message

or

1. The user enters a new record and clicks on "Save"
3. Commit is not successful
4. Application maybe retries to commit - Timeout after 5 seconds e.g.
5. User gets a message, that the record could not be saved

The question is, how to find a clean way to manage that.

Thanks

Uli

Uli...

I'm in need of exactly the same as you mention in your last post as I work with customers on very slow and lossy internet. I also need to perform some database tasks as well and need to know when data is saved.

As for timeout, I added a timeout parameter to the FHttpRequest request object and that worked like a charm on all browsers I have tested it on. See this thread for details: http://www.elevatesoft.com/forums?action=view&category=ewb&id=ewb_general&msg=5793&page=1

On 5/17/2015 2:53 AM, Uli Becker wrote:
> Assumed I have enabled a timer which checks PendingCommits and the
> commit is never successful, does PendingCommits stay at a value > 0?
> If I want to use a "TimeOut": how can I cancel a pending commit?


The whole connectivity issues will be interesting overall - one does
need connectivity just to load the app but due to browser caching it's
definitely possible one could load the app and then walk out of wifi
range while using it (especially on mobile devices).

Anyways, this is me looking at EWB2 source and Tim might have other
views on how he expects it to work so take it with (big) grain of salt.

FPendingCommits is decremented in EndCommit which is called from
RequestComplete so yes PendingCommits remains > 0 until server request
completes successfully.

Cancel option seems to be not directly accessible at this time (unless i
missed something). What i think needs to be done is basically to cancel
the current requests from internal TServerRequestQueue and then clean up
internal tdatabase commit state  (basically what "EndCommit" does today
- in fact might be ok to just call it).

This also comes into play if the back-end issues an error (say DB key
violation). Hence one would need to handle the commit failures both for
"can't connect" errors and for actual "can't commit due to bad data"
errors while connection is fine (i.e. other server requests would
succeed still since we're connected).

However with my current understanding of this i think it might be useful
to have : 1 more callback event, 1 more public function and 1 more
property :

- server request timeout property at tdatabase level that is used for
the internal TServerRequest to set request timeout

- OnAllCommitsCompleted or similar callback that fires when EndCommit is
called with FPendingCommits = 0.. It might not be a bad idea to have
callback option in RequestComplete instead also for additional flexibility.

- public function CancelCurrentCommit that you can call from
OnCommitError and that does as described above (cancel serverrequest and
call endcommit).

All of these look very straightforward to add so might just experiment
and see if i break something.

For this i will cheat now and assume the items as described above exist:

> The most common scenario would be:
>
> 1. The user enters a new record and clicks on "Save"
> 2. Commit is sucessful and the user get a message

Timer would work today - keep checking until PendingCommits=0.

i personally like the OnAllCommitsCompleted callback concept though and
once its called you proceed  (i.e. inform user or remove progress etc).

> 1. The user enters a new record and clicks on "Save"
> 3. Commit is not successful
> 4. Application maybe retries to commit - Timeout after 5 seconds e.g.

OnCommitError  is fired so you can decide to call RetryCommit if you
want to retry or once you have tried enough call CancelCurrentCommit
and inform user.

If you (can) set the server request timeout then this will be called
after that timeout so easiest might be to have a nice timeout option and
just call RetryCommit right away but if you need another wait then yes
you'd need a separate timer for that.


> 5. User gets a message, that the record could not be saved

From OnCommitError  as before (once you decide no more retries).



Raul

On 5/17/2015 4:45 AM, Eivind wrote:

> As for timeout, I added a timeout parameter to the FHttpRequest request object and that worked like a charm on all browsers I have tested it on.

I think it's still in TODO list but as you did last time we can easily
add it ourselves until Tim implements it (in FHttpRequest and actually
into the TXMLHttpRequest interface itself i think).

Raul

Raul,

very good research and excellent conclusions. Let's.wait what Tim says.

Uli

Raul wrote:

> The whole connectivity issues will be interesting overall - one does
> need connectivity just to load the app but due to browser caching
> it's definitely possible one could load the app and then walk out of
> wifi range while using it (especially on mobile devices).

Your analysis is good, but I want to pick up on this because while
generally true, it may not be. I think that if you pin the site
bookmark to the home page, then it will be caching your page, but in
any case you can open and go back to the browser at any point. More
pertinently, you can use PhoneGap to make your EWB application into an
App Store app, and in which case your connectivity might not be there
at all at startup.

These things are not important, because you should assume that you may
lose a connection at any time, and that is what is important. Assume
that any part of your connection may fail, and handle it appropriately.
Basically, know what state your data is in, and don't assume anything.
(I have one app which posts messages like to a newsgroup, but the API
can't confirm if a message was posted, so double-posts are common on
poor connections. Better service design would allow the app to ask if
the last action completed properly or not. But this is not EWB
specific, it is modern world norm.)

--

Matthew Jones

Uli,

<< 1. The user enters a new record and clicks on "Save"
3. Commit is not successful
4. Application maybe retries to commit - Timeout after 5 seconds e.g.
5. User gets a message, that the record could not be saved

The question is, how to find a clean way to manage that. >>

You'll get an OnCommitError event any time there's an issue with a commit,
period.

Tim Young
Elevate Software
www.elevatesoft.com

Eivind,

<< I'm in need of exactly the same as you mention in your last post as I
work with customers on very slow and lossy internet. I also need to perform
some database tasks as well and need to know when data is saved. >>

The important thing to remember here is:  Saved <> committed.

The commits queue up, so as far as the EWB application is concerned, you
don't need to worry about whether something committed or not, other than
knowing whether to retry commits (OnCommitError event) or give the user the
option of retrying them (PendingCommits property).

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> The question is, how to find a clean way to manage that. >>
>
> You'll get an OnCommitError event any time there's an issue with a
> commit, period.

Sure, but the question was, how to get a confirmation that the commit
(save) was successful, IOW: have I to use a timer to wait for an
OnCommitError to decide that? And how long?

Uli