Accepted, Not Yet Planned

Make publishing of containers default to publishing the contents individually

Currently, if you publish a publication or a structure group, you end up with a single publishing transaction. We've accepted this for years because it's "just the way Tridion works".

I would generally suggest that creating one big publish transaction is not what's wanted. In most reasonably large sites, if you published the root structure group, you'd probably break something. Common approaches usually involve deliberately breaking publish actions down to a smaller granularity. This gives you firstly some resilience against failures: you can republish only the things that failed. Secondly, assuming a finite amount of render threads, by publishing a lot of large SGs, you can easily tie up all your available threads for several minutes at a time, which means you won't be able to get your small-but-important job to publish straight away, even with high prio.

In general, I have my doubts about the usefulness of large transactions. There may once have been a theoretical possibility of transactional deployment of an entire site, but in practice this isn't a high priority for many people. My suggestion would be to make all publish actions on containers default to queuing the contents as individual items. Maybe you'd want to keep the current behaviour as a checkbox option. Maybe there'd need to be support for controlling the default setting for the checkbox.

I don't know how this would impact the content delivery side. At first sight, you'd imagine that smaller transactions would have less collisions/rollbacks/retries.

Dominic Cronin

  • Interesting point Travis. Makes me wonder if, having highlighted it in the items to publish, a context menu item or a button could allow you to say "Split this one". You've also got me thinking about what constitutes a large transaction. It's not just the number of items, but also how big your binaries are. Maybe Tridion should lead the way with some heuristics that aim for the best default behaviour based on the nature of a given publish request, and perhaps allow you to override that.

  • I would like to add to this, if there is some threshold of what is considered a "large publish transaction" perhaps there should also be some sort of warning on the UI. Example: if the publish job will contain more than 1000 items, then perhaps an OK/Cancel warning could display as part of the publishing window. Or at least, making that information more visible instead of hiding it in the "Show Items to Publish" drawer.

  • I agree that this is probably needed, Dom. On a few occasions I've written scripts for a clients that take a structure group tcmId and publishes all of the sub-pages as individual items.

    The most recent iteration (used following the introduction of new, empty Broker databases) also monitors the 'in flight' publish transactions to drip-feed the publish tasks to the publishers and, if a publish job fails, tries to re-publish the page two more times <-- This shouldn't strictly be needed (if everything is running tickety-boo), but helped to cut down on the number of items that had to be manually resubmitted for republishing.