CDM Brainstorm

This page contains discussions on problems & ideas for the future of the CDM. Once one of the idea and solutions discussed herein becomes mature it is recommended to create a separate page for it.

Benefit of smaller transaction borders

from a skype call with Andreas Kohlbecker and Andreas Müller on September 3rd 2012

Inspired by the specific needs of the Taxonomic Editor the we are using long running sessions. That is a session is opened and editing of taxon starts. During the editing session the taxon and almost all of the associated objects can be modified and will be stored in the end by calling for example @ITaxonNodeService.saveOrUpdate()@. The whole quite long ranging object graph is stored at once, that is in one single transaction. This has some compelling advantages:

  • if something goes wrong the whole transaction is rolled back.

  • easier development of the Taxonomic Editor

Long running sessions with far reaching transaction borders also have drawbacks which now seem to outweigh the benefits:

  • long running sessions make it hard to use Spring's HTTP invokers since it would require to mimic hibernate lazy loading trough the HTTP invokers

  • for a fine grained access control and authorization mechanism it seems beneficial to have smaller transaction borders. It then would be possible to apply the authorization directly to the according service methods like. ITaxonNodeService.saveOrUpdate()@, @IDescriptionService.saveOrUpdate() etc.

Shorter running sessions with smaller transaction borders would mean to partially dissolve the cascading strategies which are currently used during create, update and delete operations.

The shorter transaction borders could still enclose cdm object sub-graphs like the following (only a quickly scribbled list):

  • TaxonNode + Taxon

  • TaxonName

  • Description + DescriptionElement

  • References + AuthorTeam

  • Media

UPDATE (2017-01-17): Since "remoting" with http invoker has been implemented, we do not use long-running sessions anymore for TaxEditor. However, we do still have large transaction borders in terms of cascading. Cascading did change only in some details with the current implementation. The biggest issue is that we use Cascade.Merge now instead of Cascade.SaveOrUpdate.

Updated by Andreas Müller over 7 years ago · 6 revisions