New post
Question
· Sep 28, 2018

Kill object Vs %Reload()

#Coding Guidelines #Object Data Model #Caché

Method1(){

Set OID1=##class(Table).%OpenId(100)

// do Kill OID

}

&SQL(Update Table Set  Column=88)

Method2(){

Set OID2=##class(Table).%OpenId(100)

// Or do %Reload()

Set OID.Column=99

Do OID.%Save()

}

// Column 1 still holds value as 1

For getting the updated value I should do Kill OID in Method1

Discussion (4)2
Log in or sign up to continue
Vivek Ranjan · Oct 5, 2018

Yes both methods are running parallel and embedded SQL and object access are combined. My question is  object oid of a row is stored inmemory.  When you do some operation with embedded SQL the updated disk data is not updated automatically in the inmemory object. Means the open I'd should be explicitly reloaded to get the latest data from row.

The real question is whether I should kill the object oid then open it or don't kill the open Id object and just do the reload.

0 0
Dan Pasco · Oct 15, 2018

There is a more general way to describe this situation. First consider what is actually happening. When you open an Object (%Open/%OpenId) you are copying data from persistent storage into memory. Then some other actor is modifying the data in persistent storage so the in-memory data is no longer the same as the data in persistent storage. If you were to then copy the in-memory data back to persistent storage (%Save), assuming the same identifier is used, then the modifications from the other actor would be overwritten.

There are two ways that Objects/SQL Persistence will allow this to happen (I call the action performed by the other actor an underwrite). First is the case you present with your example (same process performs underwrite and overwrite). Second is when there are no or insufficient concurrency controls in place. The second case is easily resolved simply by employing proper concurrency control mechanisms to prevent under/over writes. The first case is more sinister because normal pessimistic concurrency mechanisms won't guard against this case. This case occurs when a process holds data in memory and then updates the data in persistent storage either using direct global set/kill or by using SQL. Optimistic concurrency controls will guard against only the SQL update case, direct global set/kill will go undetected unless those set/kill actions also update the version number of the data.

%Reload() was not intended to solve this problem. %Reload() is automatically invoked when the concurrency setting of an object in memory is updated from no-retained lock (value less than 3) to a retained lock (value 3 or 4). In this case, data is automatically sync'ed with data on disk to ensure that the now-lock protected data is the same in-memory and in persistent storage. However, %Reload() can be invoked directly to perform this same action should user code somehow detect it is necessary. 

If the reason you want to %Reload() the data is because the persistent storage was modified by SQL then I have the same question as Fab asked above. Why would you use SQL to update the data? I can think of a few reasons why you might want to do that but there are other ways to accomplish the same task without having to worry about the state of data in memory vs. the state of data in persistent storage.

If you were to use optimistic concurrency controls (VERSIONPROPERTY) then %Save()/UPDATE will fail if the version numbers don't match and then the user code can go into a state where conflicts can be resolved.

There is an interesting dynamic SQL feature that will guard against the case where some objects may be in memory and the user code needs to SQL to update data. I am happy to provide an example of this technique if someone is interested.

-Dan

0 0
Joel Solon · Oct 12, 2018

I think you are asking: "If I have an object open in one process, and another process updates that object or its corresponding row, what's the best way for the first process to make sure that it has the latest version of the data?"

I recommend using %Reload(). It makes it clearer to another developer what you're actually doing. A quick glance at the %Reload() code makes me think that it would be faster than killing the object and calling %OpenId() to reopen it.

Of course, you might want to make use of Concurrency options so that if you have an object open in one process, other processes are prevented from updating it.

1 0