How does the system mark an object as being checked-out persistently, i.e., on a client computer?

It uses the same gn_CheckOutTable used for ‘transient’ check-out (those used when an object is being edited in the Web interface for example) but recording the id in the relevant row of the clientSpec used for the check-out (instead of the login GUID).

E.g., this is a row in gn_CheckOutTable:

GN_OBJECTID  GN_CODE  GN_TIME      GN_USERID  GN_LOGIN                          GN_CLIENTSPECID    

-----------  -------  -----------  ---------  --------------------------------  ---------- 

2801         4        12/26/2008…  1602       00000000000000000000000000000000  2825    

It indicates that the object with id 2801 is checked-out persistently by the user with id 1602 for the clientSpec with id 2825.

Note how the gn_Login column contains all 0s, which means there is no associated login. A transient check-out for the same object is represented by a row in gn_CheckOutTable like this one:

GN_OBJECTID  GN_CODE  GN_TIME      GN_USERID  GN_LOGIN                          GN_CLIENTSPECID    

-----------  -------  -----------  ---------  --------------------------------  ---------- 

2801         4        12/26/2008…  1602       0365bd4e6fbc024e9bf15b6118db6574  0    

Note how in this case there is a login and no clientSpec id.

Persistent check-outs are not removed when the login which created them terminates (either because of a log-out or because it expires). This is what makes them persistent.

On the other hand, the transient check-outs used when editing objects in the Web interface are always removed when the associated login terminates – hence ‘transient’.

Note that both persistent and transient check-outs are specific to an object AND a certain set of access classes that indicate which attributes have been checked-out.  (This set is specified by the gn_Code column in gn_CheckOutTable). The set of access classes used for a persistent check-out is computed automatically by the system based on how the client file data is extracted from the object. If the data is the value of an attribute, the set contains just the access class of that attribute. If the data is the XML of the object, the set contains the access classes of all the object attributes. For example if an image object  is checked-out persistently, and the clientTemplate used specifies that the file data is the content of the ‘data’ attribute, the check-out is done using the access class of the ‘data’ attribute (usually ‘Content’). This means that while the object is persistently checked-out it is still possible to check-out – and modify – attributes with a different access class.