Is there any pattern for working with forms that contain a large amount of data that are not really completely unloaded and the bases are shown to the user on the UI and poisoned to the external system.

Task: There is an object which, by the way, contains a table with data. There are so many data in the table that they cannot all be raised.

  • It is necessary that the user can open this object for editing. The table supports paging.
  • It is necessary that the user can edit the data in the table.
  • It is necessary that the user can save the object after editing or cancel and not save their changes.
  • At the same time, we need a speed of response to the operation of saving the result acceptable for UI.

The question is very general. I'm interested in the approach. In particular, how to implement this with a relational database, and more precisely with JPA 2.1

What I have already tried:

  1. Versioning rows in a table. When editing the next line in the database, a new entry is created with the flag: temporary. If the operation is canceled, they are deleted by the beam, when the object is saved, their old versions are deleted and the flag is cleared.
  2. When opening an object, transfer data to a temporary storage. And flipping out of it, but it turned out to be unacceptable for a long time.
  3. There were also attempts to create temporary tables.

Share your knowledge and experience on this issue. Maybe there is a pattern or some common solution?

  • You can store the edited object itself in a separate file and load it by ID from the database when needed - Daniel Shatz
  • And where to keep it and change it until the user clicks save? - Semyon
  • one
    I would keep it in the browser, right at the user, in the same place where he edits. It makes no sense to send data to the server, if the user has not yet decided what he wants to save. - Daniel Shatz
  • Well, a lot of them. > 9000 entries for example. On the client to drag everything very expensive and then save back. This stage was passed the very first. - Semyon
  • Dragging onto the client is necessary anyway, since the user is editing on the client side. The only question is how much to drag. You can load as needed. I don’t think that a regular user will be able to edit such a number of records at the same time ... - Daniel Shatz

1 answer 1

The problem described by you is solved by the “pattern” of Conversations. An example of a “long-playing” dialogue:

  1. The first screen of the dialog opens. The data shown to the user is loaded in a separate session session and database transaction. The user can modify any dialog fields.
  2. After five minutes of editing, the user uses the UI element to save. Changes are reflected in the database. The user also expects exclusive access to the data during the editing session.

Although in the described example there are several cases of access to the database, from the user's point of view, this series of steps represents one unit of perfect work (Unit of Work). There are many ways to implement this in an application.

The first (naive) method is to keep Session sessions and transactions open while the user is editing, using database synchronization mechanisms to provide exclusive user access to editable data, and prevent other users from accessing them, ensuring isolation and atomicity. This is an anti-pattern, since unnecessary synchronization is a bottleneck for performance problems arising in high-load applications.

Another method is the use of a number of database transactions to implement a dialogue with the database. In this case, ensuring the isolation of business processes falls on the shoulders of the application. One conversation usually covers multiple transactions. Multiple database accesses can be atomic if only one transaction (usually the last one) writes to the database. All others only read the data. A typical implementation path is through the creation of a wizard-style dialog covering several steps of a request / response cycle. Hibernate includes some features that allow you to implement similar functionality:

  • Automatic Versioning: Hibernate can perform concurrency control for you. It can automatically detect whether third-party updates were made while the user was waiting.
  • Detached objects: if you choose to use the session-per-request template, all downloaded instances will be disconnected while the user is waiting. Hibernate allows you to connect objects back and save modifications. This pattern is called session-per-request-with-disconnected objects. Automatic versioning is used to isolate concurrently running queries.
  • Extended Session: A Session can be disconnected from the underlying JDBC connection after the DB transaction is committed, and reconnected when a new client request occurs. This pattern is called session-to-dialogue, which makes the reattachment of objects unnecessary. Automatic versioning is used to isolate parallel modifications, and the session cannot be flushed automatically, only explicitly.

That is, Session-to-query-with-detached-objects and session-to-talk patterns can be used to implement dialogs in Hibernate.

I use Hibernate to describe the Dialog pattern, since it definitely has built-in support for the pattern and it is described in the official documentation. It's hard for me to talk about pattern support in JPA, but fast and superficial googling shows that the pattern can be implemented in JPA.

Sources:

  1. Hibernate Developer Documentation - Chapter II. Transactions and multithreading
  2. Hibernate ORM User Guide
  3. Implementing conversations

In the last source there are examples of various implementations of the Dialog pattern.

  • Thanks for the detailed answer. Now I know that the problem even has a name. - Semyon
  • Of course, I'm interested in the option with the minimum amount of data stored in memory between requests and fast completion (saving). It turns out that this is solved by several transactions for a dialogue and versioning the changed data. - Semyon