I investigated the process of insert a instance and find that chn(cache coherence num) will be stored in a specified location (decided by slot_id and page_id) in page buffer pool just like other attributes of the instance. And when page_buffer performs flussh (pgbug_flush_all), it will write all dirty pages into file system.
So chn will be written into disk at last, is that right?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok. I can answer this question.
Yes, it is. The CHN is written into disk. All object instance has its own CHN value.
If you need more explanation about CHN, please let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No, I'm still confused.
For example, when alter a table, all its infor will be fetched into SM_TEMPLATE structure, the do_alter() will change some attributes or sth else,
and after that the changed class will be flushed to server, so tf_class_to_disk() will be called (do_alter()->dbt_finish_class()->sm_finish_class()->update_class()->allocate_disk_structures()->locator_flush_class()->
locator_mflush()->locator_class_to_disk) ,
in this function, chn will be increased and packed into disk representation of this table which will be sent to server and flushed into page buffer pool without any process.
the codes:
/* chn - need to handle overflow */
chn = class_->header.obj_header.chn + 1;
or_put_int (buf, chn);
class_->header.obj_header.chn = chn;
I notice the comments, but didn't find the place processing overflow.
Could you show me?
Thank you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As you understood, CHN (cache coherence number) is a kind of version number of the object, and its value is increased whenever the object is flushed (by converting to disk representation) to the server from the client's workspace memory because the object, which is feteched from the server into the workspace, is modified within a transaction.
This mechanism is implemented within object locator module. The locator controls the flow of objects between workspaces on the clients and the database page buffer pool on the server.
Both of objects and locks are cached for the fast access to the objects and less communication with the lock manager on the server. Cached objects are validated by the locator by comparing the cache coherency number of the copy of the object in the workspace against such number in the copy of the object in the database.
If the given chn value is the same with the stored one, then the cached object is valid so that only the client can reuse the cached object without fetching.
This chn handling is same to either class object and instance object.
Your last questino was that "what happen when the integer value of 'chn' becomes overflow by increasing 1 whenever it is modified so flushed?", right?
My answer, the two chn values are not compared by the quality of their value. It is compared by equality of them. I mean that if the two values are different, the cached object in the client's workspace and the one stored in the database are not same. The cached object is obsolete and must be old one, so that the newer one is fetched from the server.
See the call flow of xlocator_fetch() / xlocator_fetch_lockset() -> locator_return_object() -> heap_get() -> heap_get_if_diff_chn() "if (chn != NULL_CHN && scan == S_SUCCESS && chn == or_chn (&chn_recdes))".
If my explanation is not enough for your understanding, let me know.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I investigated the process of insert a instance and find that chn(cache coherence num) will be stored in a specified location (decided by slot_id and page_id) in page buffer pool just like other attributes of the instance. And when page_buffer performs flussh (pgbug_flush_all), it will write all dirty pages into file system.
So chn will be written into disk at last, is that right?
Ok. I can answer this question.
Yes, it is. The CHN is written into disk. All object instance has its own CHN value.
If you need more explanation about CHN, please let me know.
When locator performs flush behavior, chn of object will be plus 1.
So is it possible chn will overflow?
Until now, didn't you get answer about this?
Can you say which codes you are looking into?
No, I'm still confused.
For example, when alter a table, all its infor will be fetched into SM_TEMPLATE structure, the do_alter() will change some attributes or sth else,
and after that the changed class will be flushed to server, so tf_class_to_disk() will be called (do_alter()->dbt_finish_class()->sm_finish_class()->update_class()->allocate_disk_structures()->locator_flush_class()->
locator_mflush()->locator_class_to_disk) ,
in this function, chn will be increased and packed into disk representation of this table which will be sent to server and flushed into page buffer pool without any process.
the codes:
I notice the comments, but didn't find the place processing overflow.
Could you show me?
Thank you.
As you understood, CHN (cache coherence number) is a kind of version number of the object, and its value is increased whenever the object is flushed (by converting to disk representation) to the server from the client's workspace memory because the object, which is feteched from the server into the workspace, is modified within a transaction.
This mechanism is implemented within object locator module. The locator controls the flow of objects between workspaces on the clients and the database page buffer pool on the server.
Both of objects and locks are cached for the fast access to the objects and less communication with the lock manager on the server. Cached objects are validated by the locator by comparing the cache coherency number of the copy of the object in the workspace against such number in the copy of the object in the database.
If the given chn value is the same with the stored one, then the cached object is valid so that only the client can reuse the cached object without fetching.
This chn handling is same to either class object and instance object.
Your last questino was that "what happen when the integer value of 'chn' becomes overflow by increasing 1 whenever it is modified so flushed?", right?
My answer, the two chn values are not compared by the quality of their value. It is compared by equality of them. I mean that if the two values are different, the cached object in the client's workspace and the one stored in the database are not same. The cached object is obsolete and must be old one, so that the newer one is fetched from the server.
See the call flow of xlocator_fetch() / xlocator_fetch_lockset() -> locator_return_object() -> heap_get() -> heap_get_if_diff_chn() "if (chn != NULL_CHN && scan == S_SUCCESS && chn == or_chn (&chn_recdes))".
If my explanation is not enough for your understanding, let me know.
yeah, I've understood.
The situation of chn=NULL_CHN/CHN_UNKNOWN_ATCLIENT is preprocessed also.