Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

I have a Catalyst based application with a DBIx::Class model on top of an SQL database persistence layer. Following ‘best practice’ all my business logic is all within the framework and not within the database.

One particular requirement is that the date of an event is between the start date and end date of a parent object. I have a series of tests and am satisfied in my development environment this is always the case. However, in the live environment there are a number of records in the database that do not satisfy this requirement. I have realised that this is due to the high state of flux of all date values and that some users are amending the dates of the parent entities at the same time as others are creating the associated events.

I have two questions:

  1. What can I do within the framework to ensure that the requirement is met? I assume I need some sort of concurrency control. However, I need to make sure this doesn’t impact the scalability of the application more than is necessary.
  2. What tests can I write to ensure that the requirement is met, even in a multi-user environment i.e. how do you write multi-threaded tests to guarantee the concurrency controls are working as expected?

Replies are listed 'Best First'.
Re: Catalyst Concurrency Control
by Corion (Patriarch) on Feb 06, 2016 at 07:50 UTC

    I would move the data constraints into the database, as that will automatically deal with any concurrency issues.

    Note that you will face two issues when moving checks into the database:

    1. It becomes impossible for invalid configurations to exist. This means that that "unknown" data or "data we know is false but will be corrected later on" will not be able to be saved in the database. This can annoy your users or disrupt their workflow.
    2. Migration of invalid data to the new constraints will require some corrections to the database.
Re: Catalyst Concurrency Control
by Anonymous Monk on Feb 05, 2016 at 23:54 UTC

    What can I do within the framework to ensure that the requirement is met? ...

    Nothing, its not a framework issue

Re: Catalyst Concurrency Control
by Anonymous Monk on Feb 06, 2016 at 16:29 UTC

    The implication of the two replies so far is that concurrency control is not within the framework's remit and should be implemented within the database.

    Most, if not all, of the current 'business logic' is really validating data integrity - much of it complex so that it cannot be stated using database constraints. Most of this validation requires some sort of concurrency control to guarantee 100% integrity within a multi-user environment.

    However, I should be looking to move this business logic into the database - as constraints, stored procedures or triggers - in order to achieve the guarantee of data integrity I am after. Any such logic within the framework in a multi-user environment can give me no guarantees that it is actually adhered to. The framework will really end up as a transportation layer moving data for the database to the UI and back with limited additional functionality.