Skip to Main Content
HCL Domino Ideas Portal

Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.

For more information and upcoming events around #dominoforever, please visit our Destination Domino Page

Status Under Consideration
Workspace Domino
Categories General
Created by Guest
Created on Apr 25, 2024

Optimize amount of transactions

Please optimize amount of transactions. Currently many transactions are done on diffrent actions.

On low latency networks this many transactions easily sum up to several seconds for an action.


How idea:

Just send the user context (username, language, etc) and the action to process (Open Document, Action Button).

Send it to some middleware component.

This component is processing all steps, i.e. determine dialog list options, calculate computed for display fields, Refresh Document, HideWhenFormulas, ....

Send the result as a whole back.

This could be done, by sending results for each part action back to have the result like the transactional operations or as a whole document status result.

If returned as transactional operation results (in one response, as array), the client could just process the results in the order the middleware executed them (replay).

If returned as a whole document status, the client just renders the results, without thinking about anything. (set fields with no events, and so on).


So only one or maybe only a few requests have to be done instead of 50.


Example:

Form with 10 dialog Lists, 10 computed on display, 2 embedded Views.

Instead of making 1 request for form design, 1 request for document data, 10 requests for dialog list options, 10 requests for computed on display Lookups, 2 requests for embedded view design, 2 requests for embedded view content, ...

you would make one request: Open Document unid =xyz wit user context = abc

Result = All results of the requests listed before, aggregated by the middleware component on the server. Client replays results without new requests to server.

(OR Result with only field values und options for rendering)

  • Attach files
  • Guest
    Reply
    |
    Jun 25, 2024

    Thank you, for your proposal.

    Sadly local replicas can´t be used in our use case/database, because we create own key fields with sequencing numbers and do have own locking mechanisms to prevent parallel writing. These requirement forbid an editing on local replicas, because all users have to work with the same state.

    Nontheless I understand that the behaviour won´t change in the near future. This would be an own product for itsself...

  • Admin
    Thomas Hampel
    Reply
    |
    Jun 24, 2024

    I dont think that we will be changing the functionality anytime soon. For high latency networks a simple solution is to create local replicas. If you have to work 'online' the application can be designed to optimize the number of network transactions by e.g. loading lookup values upfront into a hidden field, etc.