automatic "lost update" detection

[Jan Vervecken]

hi

Please consider use-cases with these characteristics :
- (uc1) Two different users can simultaneously work with and make changes to the same record.

The ADF framework covers these use-cases as documented [1] like:
"At runtime, the framework provides automatic "lost update" detection for entity objects to ensure that a user cannot unknowingly modify data that another user has updated and committed in the meantime."

But, with sufficient load on an ADF application, such "lost updates" are not detected. [2]

I wonder how often use-cases like (uc1) really occur.
A suggested workaround is to use a change indicator attribute.

Anyone care to share his experience with use-cases like (uc1)?
Do all your relevant tables have change indicator attributes to work around this, are you using some other approach, or are some updates just "lost"?

- [1] http://docs.oracle.com/cd/E23943_01/web.1111/b31974/bcentities.htm#ADFFD200
- [2] related Oracle bugs exist, see http://java.net/jira/browse/ADFEMG-62

many thanks
Jan Vervecken

[Jan Vervecken]

hi

The lack of replies here, makes me wonder if these use-cases really must be rare.

So, the potential of multiple users simultaneously changing the same record (in an ADF application under load) ... is exceptional?

Feedback is still welcome.

thanks
Jan Vervecken

[D0natas]

Hi Jan,

IMHO it is rare, that multiple users work on a same record changing
it heavily in a *well-designed* system based on
a simple relational database normalization principles.

The reason is not technical one: workload distribution in
organisations means that it is simply not
efficient to work in parallel on the same subject (record), e.g. to
have multiple users doing almost exactly the same modifications.

Regards, Donatas

2013/2/5 Jan Vervecken <ver...@gmail.com>:

> --
> --
> You received this message because you are subscribed to the ADF Enterprise
> Methodology Group (http://groups.google.com/group/adf-methodology). To
> unsubscribe send email to adf-methodolo...@googlegroups.com
>
> All content to the ADF EMG lies under the Creative Commons Attribution 3.0
> Unported License (http://creativecommons.org/licenses/by/3.0/). Any content
> sourced must be attributed back to the ADF EMG with a link to the Google
> Group (http://groups.google.com/group/adf-methodology).
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ADF Enterprise Methodology Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to adf-methodolo...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Jan Vervecken]

Thanks for your reply Donatas.

- about "... a same record changing it heavily ..."
-- Don't get me wrong. Not that same record is under load, the ADF application as a whole is.
There is only the potential of multiple users simultaneously changing the same record.

- about "... simple relational database normalization principles ..."
and "... e.g. to have multiple users doing almost exactly the same modifications ..."
-- So, are you suggesting that if multiple users are responsible to make changes to EMPLOYEES records, some EMPLOYEES.EMAIL others EMPLOYEES.SALARY, that these should not be in the same database table?

So, in general, if you say "IMHO it is rare ...", could that imply that the automatic "lost update" detection should not be automatic (but enabled when needed, in rare use-cases)?

Would you agree that if there is a feature like automatic "lost update" detection, that it should also work when the application is under load?

regards
Jan Vervecken

[Chris Muir]

In response as per the documentation to ADF EMG issue 62
http://java.net/jira/browse/ADFEMG-62, Oracle is actively working on
ER 14651396 to address this issue. As usual no guarantees on what's
delivered but it is on our radar.

CM.

On 5 February 2013 17:33, Koen <verhul...@gmail.com> wrote:
> Whether or not it is rare, there are situations where this "behaviour" can
> and will occur. Probably users won't even notice that things went wrong.
> According to me, 2 things can be done:
>
> - Fix the bug
> - Change the documentation, warning the developer that there is no such
> thing as "lost update" detection.
>
> I strongly believe the framework should handle this.
>
> Regards,
>
> Koen Verhulst

[Jan Vervecken]

Thanks for your reply Koen.

- about "... 2 things can be done ..."
-- Sure, but another option is to implement the workaround [1] which involves adding a version column to the database table. Which we would like to avoid.
(At the same time I also wonder if a "workaround" is typically for a bug (to work around an existing feature) or for an enhancement (to implement a non-existing feature).)

- [1] https://blogs.oracle.com/smuenchadf/entry/approach_to_ensure_conflict_detection

regards
Jan Vervecken

[Jan Vervecken]

Thanks for your reply Chris.

- about "Oracle is actively working on ER 14651396 to address this issue."
-- Thanks you for the confirmation, although I am not sure what actively means here.

- about "As usual no guarantees on what's delivered ..."
-- Sure, as usual. But in this case there is also not yet a "direction", not a "faint form" that a solution could take.
For example, will a solution require changes to the application code (or even the database tables), can not yet be answered by Oracle.

regards
Jan Vervecken

[fnimphiu]

I agree that even if a problem is rare it is a problem. Sometime however the addressing of a problem is not in a fix but a document that explains what to do best if the change is intrusive to custom applications and infrastructures (e.g. database). The current issue as my understanding is addressed by the use of change indicators as documented in the JDeveloper 11g R2 documentation

"You can make the lost update detection more efficient by identifying any attributes of your entity whose values you know will be updated whenever the entity is modified.

Typical candidates include a version number column or an updated date column in the row. The change-indicator attribute's value might be assigned by a database trigger you've written and refreshed in the entity object, because you selected the Refresh on Insert or Refresh on Update option (on the Details tab). Alternatively, you can indicate that the entity object should manage updating the change-indicator attribute's value using the history attribute feature described in Section 4.10.12, "How to Track Created and Modified Dates Using the History Column." To detect whether the row has been modified since the user queried it in the most efficient way, select the Change Indicator option to compare only the change-indicator attribute values."

http://docs.oracle.com/cd/E35521_01/web.111230/e16182/bcentities.htm#sthref109

This document doesn't solve the problem "magically" in the framework but shows what can be done to avoid it-

There is an ongoing internal discussion involving development that Chris started of whether it is feasible to provide a change in the framework that doesn't require any custom changes to existing ADF BC models or if custom changes are needed.

I understand the pain that a manual change could mean for applications with hundreds of entities, but if compared to not having a solution, it might be the better choice. Anyway. Chris mentions it that this is work in progress and we will need to see what Oracle can come up with. Until then, if you face issues due to reported this passivation / affinity problem, the doc snippet above should get you out of the trouble.

Frank

[Jan Vervecken]

Thanks for your reply Frank.

Thanks for pointing to aspects in the documentation, related to the previously mentioned workaround.

- about "You can make the lost update detection more efficient ..."
-- Our goal is not to make it more efficient but to make it work under load.

- about "... this is work in progress and we will need to see what Oracle can come up with ..."
-- It makes me wonder if future versions of ADF will be able (or want) to support a feature like automatic "lost update" detection.

regards
Jan Vervecken

[D0natas]

2013/2/5 Jan Vervecken <ver...@gmail.com>:

> - about "... simple relational database normalization principles ..."
> and "... e.g. to have multiple users doing almost exactly the same
> modifications ..."
> -- So, are you suggesting that if multiple users are responsible to make
> changes to EMPLOYEES records, some EMPLOYEES.EMAIL others EMPLOYEES.SALARY,
> that these should not be in the same database table?

the same table is fine here - for the exceptional case the company X
of employee Y
decides to change his email address, increase (or decrease) his salary
and assign 100 back office colleagues to
proceed with modifications (heavy load) of employee Y record at the
same time :)

And even then - in case an optimistic locking leaks under heavy load
- the last modification "wins" , so
the end result should by fine in this case, because i assume the data
all 100 back office colleagues are trying to
push into the system (a new email and a new salary) is the same.

>
> So, in general, if you say "IMHO it is rare ...", could that imply that the
> automatic "lost update" detection should not be automatic (but enabled when
> needed, in rare use-cases)?

IMHO it is fine to have this feature automatically enabled.

>
> Would you agree that if there is a feature like automatic "lost update"
> detection, that it should also work when the application is under load?

Of course - normally optimistic locking should't leak also under heavy load.

According to Chris the issue is under radar so i assume somebody at
Oracle is actively
considering all options (like versioning, checksum, timestamp etc.) to
make an optimistic locking in ADF reliable under heavy load.

Thanks for making aware about this issue - it is good to know in advance.

Someone familiar with optimistic locking implementation details in ADF
BC might probably provide an insight when it happens and
what does a "heavy load" mean - more than one concurrent modification
per second, millisecond ..?

Regards, Donatas

[Jan Vervecken]

Thanks for your reply Donatas.

- about "... the last modification "wins" , so the end result should by fine in this case, because i assume the data ... is the same ..."
-- That is not always a valid assumption for every use-case.

- about "Thanks for making aware about this issue - it is good to know  in advance."
-- You're welcome.

- about "... what does a "heavy load" mean ..."
-- Where I wrote "sufficient load" in this discussion thread, I was alluding on load that causes passivation and activation to occur (which can be simulated with "-Djbo.ampool.doampooling=false" configured, see http://java.net/jira/browse/ADFEMG-62 ).

regards
Jan Vervecken

[Jan Vervecken]

Thanks for your reply Saif Kamaal, and for sharing your experience.

regards
Jan Vervecken

On Tuesday, February 5, 2013 5:12:22 PM UTC+1, Saif Kamaal wrote:

All,

We did an EBS integration development couple of yrs back 2010 i guess and i remember post production users sporadically shouting for lost updates and record lock issues. The application was developed in 11.1.1.4 and the issue couldn't be reproduced from IT side. Seems a potential "lost update" issue to me now O.O ?

Regards,
Saif Kamaal.

[Jan Vervecken]

fyi

About the suggested workaround with a Change Indicator attribute, find some related questions in OTN forum thread "Signal Row Modified By Another User Exception Even When AMPooling Disabled "
at https://forums.oracle.com/forums/thread.jspa?threadID=2497750

regards
Jan Vervecken

On Tuesday, February 5, 2013 1:35:31 PM UTC+1, fnimphiu wrote: