Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Row Locking with JPADatasource

    Is there a way to lock a database row from concurrent editing with JPADataSource?

    Thanks

    #2
    No. Generally speaking row locking is not an approach used with web or WAN applications.

    Optimistic concurrency can be achieved by using dsRequest.oldValues to check whether the record has been changed since the user loaded data from the database. Or, a more formal approach can be used such as having a column that tracks the last modification (there is built-in support for this via the DataSourceFieldType "modifierTimestamp").

    Comment


      #3
      It sounds like either of these approaches could be used to handle the scenario where, for example, another process updates a record using hibernate/JPA where the datasource most likely is not aware that the change was made.

      Is that a correct assumption?

      Thanks,
      Last edited by ls3674; 2 Jan 2012, 10:34.

      Comment


        #4
        Yes, either of the approaches mentioned above could be used to *detect* that situation and avoid an update from a user that was looking at stale data (or add confirmation of the update, etc). To actually stream updated from another process to a given user, the Messaging module should be used.

        Comment


          #5
          So, how can a race condition be avoided between the Isomorphic read/compare and a write operation from a non-Isomorphic bean without row locking?

          Thanks,

          Comment


            #6
            If you mean a race condition where, during the server-side processing of the save, the dsrequest.oldValues are checked against the DB, found to be up to date, then some other bean writes to the DB? Just make sure the check of oldValues is in the same transaction as the actual update. To do this, just make sure the DSRequest you create to check the oldValues has had setRPCManager() called on it (see server-side JavaDoc for this method).

            If you're concerned that your database engine may not provide transaction isolation for non-repeatable reads, another approach is to add all the oldValues as criteria for the SQL update. Concurrent write is then detectable because no rows will be affected.

            Comment

            Working...
            X