Isis
  1. Isis
  2. ISIS-248

Perform concurrency checking within the persistor (rather than rely on every viewer/client to do the check)

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.2.0-incubating
    • Fix Version/s: core-1.0.0
    • Component/s: Core
    • Labels:
      None

      Description

      Currently it is the responsibility of each viewer to check whether a domain object has been updated prior to completing an edit.

      For example, if an object is displayed, the viewer renders the OID (usually in the HTML) and also caches the version of the object somewhere (either in the HTML, or possibly in a http session). If the user then invokes an action, then the viewer resolves the object and checks that the version has not changed.

      This ticket is to move this check into the persistor so that, when an object is resolved, the version is also supplied. The persistor then throws a concurrency check if there is a mismatch.

      The intention is for the API of the Persistor to remain unchanged, accepting only an Oid to resolve the object, but to use the version details that can now be stored in the Oid (see ISIS-245).

        Activity

        Hide
        Dan Haywood added a comment -

        HERE'S THE DETAIL OF A MAIL I SENT TO isis-dev RELATING TO THIS TICKET.
        – Dan
        ~~~~~~~~~

        Some of the recent commits I've been doing now allow the version information (a sequence, and an optional user and timestamp) to be stored in the RootOid. This version information, if present, isn't part of the equals()/hashCode() equivalence checks, but is serialized out as part of the state. As such, it constitutes a convenient way for a viewer to capture the version of an object that has been rendered, just by serializing the Oid. This commits were done under the general slew of commits under ISIS-14 (the JDO object store), and are non-breaking.

        Concurrently with this, the existing Version interface, as referenced by ObjectAdapter/PojoAdapter, also holds a sequence, user and date. ISIS-245 was a ticket I worked on yesterday, which collapsed to Version hierarchy (Version being an interface, and SerialNumberVersion and FileVersion being the two implementations) into a single class, called Version. I've retained SerialNumberVersion and FileVersion, but their only distinguishing responsibility was to act as a factory (providing defaults for the different fields of Version).

        I then retrofitted the version information within RootOid so that it holds a reference to Version.

        All of the above is just a refactoring, and should be non-breaking.

        ISIS-248, finally, was another ticket I worked on yesterday, in which the version field on ObjectAdapter disappears, and instead the ObjectAdapter delegates to its Oid for the version information. Any call to set the version (following an update) on the ObjectAdapter is delegated on similarly.

        The new, breaking, change is the following check that's been added in AdapterManagerDefault (the class that retrieves the object from the datastore):

        @Override
        public ObjectAdapter adapterFor(final TypedOid typedOid) {

        // attempt to locate adapter for the Oid
        final ObjectAdapter adapterLookedUpByOid = getAdapterFor(typedOid);
        if (adapterLookedUpByOid != null)

        { return adapterLookedUpByOid; }

        final Object pojo = pojoRecreator.recreatePojo(typedOid);
        ObjectAdapter adapter = mapRecreatedPojo(typedOid, pojo);

        // START: ISIS-148 change
        Oid adapterOid = adapter.getOid();
        if(adapterOid instanceof RootOid)

        { final RootOid recreatedOid = (RootOid) adapterOid; final RootOid originalOid = (RootOid) typedOid; recreatedOid.checkLock(getAuthenticationSession().getUserName(), originalOid); }

        // END: ISIS-148 change

        return adapter;
        }

        It ought now to be possible to start removing concurrency checks from the viewers (Scimpi, HTML etc), while those viewers that don't yet do proper concurrency checking (Wicket, Restful) will get this for free (but need to handle any ConcurrencyExceptions that could now propogate out of the persistor.

        Show
        Dan Haywood added a comment - HERE'S THE DETAIL OF A MAIL I SENT TO isis-dev RELATING TO THIS TICKET. – Dan ~~~~~~~~~ Some of the recent commits I've been doing now allow the version information (a sequence, and an optional user and timestamp) to be stored in the RootOid. This version information, if present, isn't part of the equals()/hashCode() equivalence checks, but is serialized out as part of the state. As such, it constitutes a convenient way for a viewer to capture the version of an object that has been rendered, just by serializing the Oid. This commits were done under the general slew of commits under ISIS-14 (the JDO object store), and are non-breaking. Concurrently with this, the existing Version interface, as referenced by ObjectAdapter/PojoAdapter, also holds a sequence, user and date. ISIS-245 was a ticket I worked on yesterday, which collapsed to Version hierarchy (Version being an interface, and SerialNumberVersion and FileVersion being the two implementations) into a single class, called Version. I've retained SerialNumberVersion and FileVersion, but their only distinguishing responsibility was to act as a factory (providing defaults for the different fields of Version). I then retrofitted the version information within RootOid so that it holds a reference to Version. All of the above is just a refactoring, and should be non-breaking. ISIS-248 , finally, was another ticket I worked on yesterday, in which the version field on ObjectAdapter disappears, and instead the ObjectAdapter delegates to its Oid for the version information. Any call to set the version (following an update) on the ObjectAdapter is delegated on similarly. The new, breaking, change is the following check that's been added in AdapterManagerDefault (the class that retrieves the object from the datastore): @Override public ObjectAdapter adapterFor(final TypedOid typedOid) { // attempt to locate adapter for the Oid final ObjectAdapter adapterLookedUpByOid = getAdapterFor(typedOid); if (adapterLookedUpByOid != null) { return adapterLookedUpByOid; } final Object pojo = pojoRecreator.recreatePojo(typedOid); ObjectAdapter adapter = mapRecreatedPojo(typedOid, pojo); // START: ISIS-148 change Oid adapterOid = adapter.getOid(); if(adapterOid instanceof RootOid) { final RootOid recreatedOid = (RootOid) adapterOid; final RootOid originalOid = (RootOid) typedOid; recreatedOid.checkLock(getAuthenticationSession().getUserName(), originalOid); } // END: ISIS-148 change return adapter; } It ought now to be possible to start removing concurrency checks from the viewers (Scimpi, HTML etc), while those viewers that don't yet do proper concurrency checking (Wicket, Restful) will get this for free (but need to handle any ConcurrencyExceptions that could now propogate out of the persistor.
        Hide
        Dan Haywood added a comment -

        rev: 1376402

        Show
        Dan Haywood added a comment - rev: 1376402
        Hide
        Dan Haywood added a comment -

        prior to generating 1.0.0 release notes

        Show
        Dan Haywood added a comment - prior to generating 1.0.0 release notes

          People

          • Assignee:
            Dan Haywood
            Reporter:
            Dan Haywood
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development