Adichatz manages an application data cache on the client side in order to provides these features:

  • Only needed queries are send to the Application Server (JEE context) or to the database (JSE Context): Adichatz requests the data cache before requesting the server.
  • Lazy loading is managed directly by the application. You do not have to program access to the database.
  • Consistency of data between several editors is provided by Adichatz:
    • an entity could by updated only in one editor.
    • updates on an entity is rolled out to other editors, including in tables, including creation and deletion of new rows according to change on ManyToMany or ManytoOne fields.
    • refresh process when canceling changes roll back changes in all the editors.
  • Listeners on entity or databinding service provide a useful way to associate processes to entity events.
  • Adichatz provides in standard a plain solution for managing locks in JEE context. An entity could be updated by only one session.
  • A validation process allows to control data when displaying, updating or before saving changes.


Principle of the data cache is simple. Each bean (pojo or entity bean) provided by the JPA layer is wrapped into an Adichatz Entity from the moment it must be managed by an editor.

  1. Application receives beans (POJOs) from JPA layer.
  2. From the moment the bean is managed by an editor, it is wrapped into an Entity. A decision tree containing required lazy fetches is associated to the bean. Required lazy loading is managed editor by editor.
  3. Beans of entities are sent to JPA layer when an action ask for a persistent features.

As shown in the figure, the application data cache is closely linked to the concept of databinding service.