[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: <bug>: neuen Pat. aufgerufen
From: |
Karsten Hilbert |
Subject: |
Re: <bug>: neuen Pat. aufgerufen |
Date: |
Mon, 7 Jun 2021 11:29:05 +0200 |
Hello Karsten,
> user comment : neuen Pat. aufgerufen
>
> client version: 1.8.5
>
> system account: gnumed
> staff member : Karsten Heinrich (KaHe = kahe)
> sender email : <E-Mail eintragen für Rückmeldungen zum Fehler>
>
> # enable Launchpad bug tracking
> affects gnumed
> tag automatic-report
> importance medium
>
> Exception:
>
> type: <class 'Gnumed.pycommon.gmExceptions.ConstructorError'>
> value: [cEncounter:50973]: error loading instance
>
> Traceback:
>
> File "/usr/lib/python3/dist-packages/wx/core.py", line 3259, in <lambda>
> lambda event: event.callable(*event.args, **event.kw) )
> File "/usr/share/gnumed/Gnumed/business/gmClinicalRecord.py", line 261, in
> db_modification_callback
> curr_enc_in_db = gmEMRStructItems.cEncounter(aPK_obj =
> self.current_encounter['pk_encounter'])
> File "/usr/share/gnumed/Gnumed/pycommon/gmBusinessDBObject.py", line 335,
> in __init__
> self.__init_from_pk(aPK_obj = aPK_obj, link_obj = link_obj)
> File "/usr/share/gnumed/Gnumed/pycommon/gmBusinessDBObject.py", line 363,
> in __init_from_pk
> raise gmExceptions.ConstructorError("[%s:%s]: error loading instance" %
> (self.__class__.__name__, self.pk_obj))
The problem you have seen is very interesting (and hopefully
fixed now).
While your client was having open a patient with a specific
encounter being active another client seems to have opened
that same patient and have somehow effected a deletion of
that active encounter. Your client receives a database change
notification:
> File "/usr/share/gnumed/Gnumed/business/gmClinicalRecord.py", line 261, in
> db_modification_callback
and tries to load the encounter to check for what changes
have been applied remotely, if any:
> curr_enc_in_db = gmEMRStructItems.cEncounter(aPK_obj =
> self.current_encounter['pk_encounter'])
That fails, however:
> raise gmExceptions.ConstructorError("[%s:%s]: error loading instance" %
> (self.__class__.__name__, self.pk_obj))
because the change was a DELETE:
> 2021-06-02 16:54:03 DEBUG gm.logging [3082571456 MainThread]
> (/usr/share/gnumed/Gnumed/pycommon/gmLog2.py::log_stack_trace() #213):
> kwds = {'signal': 'gm_table_mod', 'sender': None,
> 'originated_in_database': True, 'listener_pid': 12389, 'sending_backend_pid':
> 21921, 'pk_identity': 12812, 'operation': 'DELETE', 'table':
> 'clin.encounter', 'pk_column_name': 'pk', 'pk_of_row': 50973,
> 'message_index': 2491, 'notification_index': 1246}
IOW, the encounter is now *gone* and cannot be reloaded.
There's a fairly complex maze of things to be considered :-)
1) GNUmed did not, at all, take into account that
possibility, and reacted disgracefully, as you
discovered.
It now does, by newly attaching to (a) current encounter.
2) It was not thought possible for the currently active
encounter to disappear because GNUmed uses a lock on it.
However, the lock, while being held *inside* the
database, is only by co-operation (an advisory lock) and
is not being held *on* the encounter directly.
There's two ways the lock can be overcome that I can think of:
1) The encounter in question
is older than either 3 days or the defined minimum
encounter age (whichever is longer) -- IOW, the client
holding the encounter as active has been open for three
days on that patient, and
is "empty", and
is one of more than 2 encounters for that patient
In this case, when another client comes along and opens the
patient, it will instruct the database to delete "old empty
encounters" on its behalf, WHICH DOES NOT CHECK THE LOCK.
It now does.
2) There is a (client) coding error regarding the lock.
I can't find one, however.
So, this *should* not happen anymore ...
Best,
Karsten
--
GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B