Home › Forums › Developers › General developer's discussion ›

Financial Act Locking any other options

Submitted by Ben_Charlton on Thu, 26/03/2015 - 18:08
in

We see quite  a few 

Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [org.openvpms.component.business.dao.hibernate.im.act.FinancialActDOImpl] 
 

errors, usually due to someone processing a checkout before the vet is done completely with billing during the workflow.

OR a nurse adding a lead/collar etc to the bill while the vet has a open consult screen.  

vet loses thier changes because its last to open wins currently.

Do we have any other options to avoid 2 people opening an invoice at the same time and the first person loosing any changes?

 

Ben

‹ Jira Capture Plugin Bitbucket Domain Name Change ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: Financial Act Locking any other options

Submitted by Ben_Charlton on Thu, 26/03/2015 - 18:13.

Perhaps a better option is that we actually handle the exception and dont throw a reportable error.  ie Give the user the error and explanation that someone else has editted the invoice and thier changes have been lost.

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: Financial Act Locking any other options

Submitted by tanderson on Fri, 27/03/2015 - 09:44.

There are a few things that should be done to improve this:

  1. improve the error message, and remove the option to report the error
  2. allow the user to reload the object for editing rather than locking the dialog
  3. include the user that last edited the object in the error message. This needs change logging support
  4. add support for edit locks

Change logging

There is currently no way to determine who last edited an object.

Primary objects (acts, entities, parties, users, and lookups should be able to track who created them, and who last updated them.

This can be done by referencing a log table that identifies who saved something, and when it was saved i.e. it would contain:

  • the user
  • the timestamp

A primary object would have a creation log record and an update log record if it has been modified.

The database layer would automatically generate a log record each time an object is saved. These records would be shared; if a transaction saves multiple objects, each object references the same log record. Unreferenced log records would be removed. This way, there will only ever be at most (2*total primary objects) log records in the database.

This would also:

  • remove the need for participation.author on acts
  • remove the need for createdDate on party.patientpet
  • improve reporting options

Edit locks

Edit locks would enable a user to acquire a lock on an object to prevent:

  • other users from editing it
  • business rules updating a locked object

The lock would automatically be acquired when editing an object, and lock related objects as well.

There would need to be support to:

  • administratively remove locks
  • expire locks if a user is inactive for a period of time
  • prevent deadlocks

 

Re: Financial Act Locking any other options

Submitted by Ben_Charlton on Fri, 27/03/2015 - 09:55.

I think most of those options seem resonable the only 1 that I see as a issue is the Edit Locks - I have been involved in management systems that implemented optimistic locking in the past - and it invariably caused issues...getting expiry correct varied daily -  and almost constant administration releasing locks.

Ie people seemed to always want a different behaviour.  Given the lack of complaints despite the errors I think avoid locking and just go with logging and improving the error messages.

 

Regards
 
Ben 
OpenVPMS Installer and Helper 
Ph: +61423044823 
Email: info[at]charltonit.com[dot]au

Re: Financial Act Locking any other options

Submitted by tgething (not verified) on Sat, 28/03/2015 - 05:59.

I am a little concerned about the:

  • remove the need for participation.author on acts
  • remove the need for createdDate on party.patientpet

The RxWorks system included a date & author for both created and last-modified in its 'entity files' - ie the customer, patient, product & supplier files and also and author in the transaction files.

This information was useful when looking for problems and screwups. [Who changed the xxxx and when ???]

I do admit that the author was simply the login name, and thus low overhead to insert compared to our participation link.

I would like to see as much 'traceability' as possible in the system, and I don't really care about referential integrity in the author information.  That is, if I am chasing a 'who did what when' problem I can cope with just having a text user login name.

We also currently use the participation.author on acts to display author info on the transaction screens - eg

The highlighted ones are authors, for invoices (and credits) we show the clinician - DG in the above.

Regards, Tim G

Re: Financial Act Locking any other options

Submitted by tanderson on Sat, 28/03/2015 - 10:02.

You'd still have access to the author information - it would just be stored differently, and potentially linked to multiple objects.

So instead of:

openvpms:get(., "author.entity.name")

you might have:

openvpms:get(., "created.user.name")
openvpms:get(., "created.user.time")
openvpms:get(., "updated.user.time")
openvpms:get(., "updated.user.time")

 

Re: Financial Act Locking any other options

Submitted by tanderson on Tue, 26/05/2015 - 12:21.

I've started documenting a new project for this here: http://www.openvpms.org/project/add-created-and-updated-details-primary-...

Syndicate content