Uploaded image for project: 'eZ Publish / Platform'
  1. eZ Publish / Platform
  2. EZP-28681

Legacy transaction handling issues

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: High
    • Resolution: Fixed
    • Affects Version/s: 4.7 Maintenance, 5.3.12, 2017.12, 2018.06, 5.4.12, 2018.09
    • Fix Version/s: Customer request
    • Component/s: Legacy stack, QA
    • Labels:

      Description

      I have discovered a few issues related to how Legacy handles transactions during operations on versions (publishing, saving, discarding):

      1. EZP-29796 During the autosave, the status checks are performed (https://github.com/ezsystems/ezautosave/blob/master/classes/ezjscserverfunctionsautosave.php#L107) before the transaction begins (https://github.com/ezsystems/ezautosave/blob/master/classes/ezjscserverfunctionsautosave.php#L205). This means that if this version is published in the meantime (or archived, basically any status change) then during the transaction the status will be set back to draft, which leads to inconsistencies (no published version).

      2. EZP-29797 During discarding the draft, the attributes are deleted first and without the transaction (https://github.com/ezsystems/ezpublish-legacy-ee/blob/master/kernel/classes/ezcontentobjectversion.php#L923 and https://github.com/ezsystems/ezpublish-legacy-ee/blob/master/kernel/classes/ezcontentobjectversion.php#L927 ; `removeThis()` method call is not wrapped in the transaction either). If the request stops right before the transaction or the transaction rollbacks, then attributes will be deleted, but version with the draft will still be there, which in turn makes the draft no longer editable (if you try to edit this version, then no attributes are shown, so there is nothing to edit).

      3. EZP-29798 During discarding the draft, the status checks are performed (https://github.com/ezsystems/ezpublish-legacy-ee/blob/master/kernel/content/removeeditversion.php#L32) before the transaction begins. This means that if this version is published in the meantime (or archived, basically any status change) then during the transaction it will be removed, which leads to inconsistencies (no published version).

      4. EZP-29799 During the publishing of the draft, the status of the current version is changed to Archived. However, the current version is retrieved from the object which is cached in a global variable (https://github.com/ezsystems/ezpublish-legacy-ee/blob/master/kernel/content/ezcontentoperationcollection.php#L134), so the current version might be outdated if another version is published simultaneously. If this happens, the Content Object will have two Published versions.

      5. EZP-29800 (with DFS configured) During the cache purge, called by example via php bin/php/ezcache.php --clear-all --purge command, the _purgeByLike method is called (https://github.com/ezsystems/ezpublish-legacy-ee/blob/5.4/kernel/private/classes/clusterfilehandlers/dfsbackends/mysqli.php#L337). This method deletes file metadata in the transaction, however, it also deletes the physical file regardless of the transaction result: https://github.com/ezsystems/ezpublish-legacy-ee/blob/5.4/kernel/private/classes/clusterfilehandlers/dfsbackends/mysqli.php#L393. If the transaction fails, this causes the content view cache to NOT be regenerated correctly (because the metadata for the cache file still exists) and instead the blank page is displayed.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              Unassigned
              Reporter:
              sylvain.guittard@ez.no Sylvain Guittard
              Votes:
              3 Vote for this issue
              Watchers:
              9 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - 0 minutes
                  0m
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 2 weeks, 1 day, 5 hours, 47 minutes
                  2w 1d 5h 47m