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

Legacy transaction handling issues

    XMLWordPrintable

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: High High
    • Customer request
    • 4.7 Maintenance, 5.3.12, 2017.12, 2018.06, 5.4.12, 2018.09
    • Legacy stack, QA

    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

        Activity

          People

            Unassigned Unassigned
            sylvain.guittard@ibexa.co 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