{"id":11017,"date":"2018-03-18T21:03:33","date_gmt":"2018-03-18T20:03:33","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/"},"modified":"2018-03-18T21:03:33","modified_gmt":"2018-03-18T20:03:33","slug":"result-cache-invalidation-caused-by-dml-locks","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/","title":{"rendered":"Result cache invalidation caused by DML locks"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nIn a previous post<\/a> about Result Cache, I was using ‘set autotrace on’ in my session to see when the result cache hit saves the logical reads. I got a comment, by e-mail and with full test case, mentioning that the invalidation I had when doing some DML does not occur when autotrace is set to off. I reproduced the problem, on 18c because I use my cloud services to do my tests, but it works the same way in 12c.
\n
\nI’ll focus here on DML which does not modify any rows from the table the result depends on, because this is the case that depends on the session transaction context. When rows are modified, the result is always invalidated.<\/p>\n

For each test here I’ll flush the result cache:<\/p>\n

\nSQL> exec if dbms_result_cache.flush then dbms_output.put_line('Flushed.'); end if;\nPL\/SQL procedure successfully completed.\n \nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\nno rows selected\n<\/code><\/pre>\n
And I begin each test with the result cache loaded by a query.<\/p>\n
DML on the dependent table<\/h3>\n
The result or the query is loaded into the cache, with a dependency on the SCOTT.DEPT table:<\/p>\n
\nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n \n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n  -- ----         ------      ----                                            --------                       -------------\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 0\n   1 Result       Published   select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n<\/code><\/pre>\n
Now, I’m executing some DML on this DEPT table:<\/p>\n
\nSQL> connect scott\/tiger@\/\/localhost\/PDB1\nConnected.\nSQL> delete from DEPT where DEPTNO>40;\n0 rows deleted.\n<\/code><\/pre>\n
This delete does not touch any row, but declares the intention to modify the table with a Row eXclusive lock (TM mode=3):<\/p>\n
\nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\n \n  OBJECT_ID   XIDUSN   XIDSLOT   XIDSQN   SESSION_ID ORACLE_USERNAME   OS_USER_NAME   PROCESS     LOCKED_MODE   CON_ID OBJECT_NAME\n  ---------   ------   -------   ------   ---------- ---------------   ------------   -------     -----------   ------ -----------\n      73376        0         0        0           21 SCOTT             oracle         7772                  3        5 DEPT\n<\/code><\/pre>\n
Note that the transaction ID is all zeros. Logically, we are in a transaction, as we have a lock that will be released only at the end of the transaction (commit or rollback). But, as we didn’t modify any block yet, there is no entry in the transaction table:<\/p>\n
\nSQL> select xidusn,xidslot,xidsqn,start_time,used_urec from v$transaction\nno rows selected\n<\/code><\/pre>\n
I commit this transaction:<\/p>\n
\nSQL> commit;\nCommit complete.\n<\/code><\/pre>\n
and check the result cache objects:<\/p>\n
\nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n \n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n  -- ----         ------      ----                                            --------                       -------------\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 0\n   1 Result       Published   select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n<\/code><\/pre>\n
This look good: nothing was modified so there is no reason to invalidate the result. However, in the previous post I referenced, a similar test invalidated the cache even when no rows were touched. And a reader remarked that this occured only when I previously run a query with ‘autotrace on’. Without autotrace, the behaviour is like what I show here above: no invalidation when no rows is modified.<\/p>\n
Same in an already started transaction<\/h3>\n
The difference is that the ‘autotrace on’ runs an ‘explain plan’, filling the plan table, which means that a transaction was already started. Here I run autotrace on a completely different query:<\/p>\n
\nSQL> set autotrace on explain\nAutotrace Enabled\nDisplays the execution plan only.\nSQL> select * from dual;\nDUMMY\n-----\nX\n \nExplain Plan\n-----------------------------------------------------------\nPLAN_TABLE_OUTPUT\nPlan hash value: 272002086\n \n--------------------------------------------------------------------------\n| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |\n--------------------------------------------------------------------------\n|   0 | SELECT STATEMENT  |      |     1 |     2 |     2   (0)| 00:00:01 |\n|   1 |  TABLE ACCESS FULL| DUAL |     1 |     2 |     2   (0)| 00:00:01 |\n--------------------------------------------------------------------------\n \nSQL> set autotrace off;\nAutotrace Disabled\n<\/code><\/pre>\n
Following this, I have no locked objects, but a transaction has been initiated:<\/p>\n
\nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\nno rows selected\n \nSQL> select xidusn,xidslot,xidsqn,start_time,used_urec from v$transaction\n  XIDUSN   XIDSLOT   XIDSQN START_TIME            USED_UREC\n  ------   -------   ------ ----------            ---------\n       9        18      709 03\/18\/18 20:30:09             2\n<\/code><\/pre>\n
Here is the big difference: I have a transaction ID here.
\nNow doing the same as before, a delete touching no rows:<\/p>\n
\nSQL> delete from DEPT where DEPTNO>40;\n0 rows deleted.\n<\/code><\/pre>\n
When I query the lock objects, they are now associated to a non-zero transaction ID:<\/p>\n
\nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\n \n  OBJECT_ID   XIDUSN   XIDSLOT   XIDSQN   SESSION_ID ORACLE_USERNAME   OS_USER_NAME   PROCESS     LOCKED_MODE   CON_ID OBJECT_NAME\n  ---------   ------   -------   ------   ---------- ---------------   ------------   -------     -----------   ------ -----------\n      73376        9        18      709           21 SCOTT             oracle         7772                  3        5 DEPT\n<\/code><\/pre>\n
Here is the difference, now the result cache has been invalidated:<\/p>\n
\nSQL> commit;\nCommit complete.\n \nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n \n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n  -- ----         ------      ----                                            --------                       -------------\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 1\n   1 Result       Invalid     select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n<\/code><\/pre>\n
DML on another table – RS though referential integrity<\/h3>\n
\"CaptureLocks\"<\/a>This gives the idea that the invalidation is not really triggered by actual modifications, but at commit time from the DML locks when associated with a transaction.
\nAnd some DML on tables may acquire a Row-S or Row-X lock on the tables linked by referential integrity. This has changed a lot though versions – look at the slide on the right.<\/p>\n
I start in the same situation, with the result cache loaded, no locked objects, but a transaction that has started:<\/p>\n
\nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n \n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n  -- ----         ------      ----                                            --------                       -------------\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 0\n   1 Result       Published   select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n \nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\nno rows selected\n \nSQL> select xidusn,xidslot,xidsqn,start_time,used_urec from v$transaction\n \n  XIDUSN   XIDSLOT   XIDSQN START_TIME            USED_UREC\n  ------   -------   ------ ----------            ---------\n       8        31      766 03\/18\/18 20:30:10             2\n<\/code><\/pre>\n
I delete from the EMP table and if you are familiar with the SCOTT schema, you know that it has a foreign key to DEPT. <\/p>\n
\nSQL> delete from EMP where DEPTNO>=40;\n0 rows deleted.\n<\/code><\/pre>\n
The delete acquires a Row eXclusive lock on EMP even when there are no rows deleted (DML locks are about the intention to modify rows). And from the table above, it acquires a Row Share (mode=2) on the parent table:<\/p>\n
\nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\n \n  OBJECT_ID   XIDUSN   XIDSLOT   XIDSQN   SESSION_ID ORACLE_USERNAME   OS_USER_NAME   PROCESS     LOCKED_MODE   CON_ID OBJECT_NAME\n  ---------   ------   -------   ------   ---------- ---------------   ------------   -------     -----------   ------ -----------\n      73376        8        31      766           21 SCOTT             oracle         7772                  2        5 DEPT\n      73378        8        31      766           21 SCOTT             oracle         7772                  3        5 EMP\n<\/code><\/pre>\n
I commit and check the result cache:<\/p>\n
\nSQL> commit;\nCommit complete.\n \nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n \n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n  -- ----         ------      ----                                            --------                       -------------\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 0\n   1 Result       Published   select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n<\/code><\/pre>\n
No invalidation here, which makes sense because Row Share is not an intention to write.<\/p>\n
DML on another table – RX though referential integrity<\/h3>\n
I do the same here, but with an insert on EMP which acquires a Row eXclusive on the parent table.<\/p>\n
\nSQL> insert into EMP(EMPNO,DEPTNO)values(9999,40);\n1 row inserted.\n \nSQL> select * from v$locked_object natural join (select object_id,object_name from user_objects)\n \n  OBJECT_ID   XIDUSN   XIDSLOT   XIDSQN   SESSION_ID ORACLE_USERNAME   OS_USER_NAME   PROCESS     LOCKED_MODE   CON_ID OBJECT_NAME\n  ---------   ------   -------   ------   ---------- ---------------   ------------   -------     -----------   ------ -----------\n      73376       10        32      560           21 SCOTT             oracle         7772                  3        5 DEPT\n      73378       10        32      560           21 SCOTT             oracle         7772                  3        5 EMP\n \nSQL> select xidusn,xidslot,xidsqn,start_time,used_urec from v$transaction\n \n  XIDUSN   XIDSLOT   XIDSQN START_TIME            USED_UREC\n  ------   -------   ------ ----------            ---------\n      10        32      560 03\/18\/18 20:30:10             4\n \nSQL> commit;\nCommit complete.\n \nSQL> select id,type,status,name,cache_id,invalidations from v$result_cache_objects order by id\n---- ------ ------------------------------------------ ---- ---------------------- ----- -- --\n  ID TYPE         STATUS      NAME                                            CACHE_ID                       INVALIDATIONS\n   0 Dependency   Published   SCOTT.DEPT                                      SCOTT.DEPT                                 1\n   1 Result       Invalid     select \/*+ result_cache *\/ count(*) from DEPT   50vtzqa5u0xcy4bnh6z600nj1u                 0\n<\/code><\/pre>\n
Here, DEPT has been invalidated after the insert on EMP. There were no modifications on DEPT, but the result cache is not directly tracking the modifications, but rather the intention of modification. And then, the implementation of the result cache invalidation tracks, at commit, the Row eXclusive locks when they are related to a know transaction. You can have the same result if, from a transaction that has already started, you run a simple:<\/p>\n
\nSQL> lock table DEPT in row exclusive mode;\nLock succeeded.\n<\/code><\/pre>\n
This means that there are many reasons why the result cache may be invalid even when the objects in the ‘Dependency’ are not modified. Be careful, invalidations and cache misses are expensive and do not scale on high load. And because of locks through referential integrity, this can happen even on static tables. Let’s take an example. in an order entry system, you may think that the ‘products’ table is a good candidate for result cache – updated twice a year but read all the times. But now that you know that inserts on child tables, such as the order table, will invalidate this cache, you may think again about it.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . In a previous post about Result Cache, I was using ‘set autotrace on’ in my session to see when the result cache hit saves the logical reads. I got a comment, by e-mail and with full test case, mentioning that the invalidation I had when doing some DML does not occur […]<\/p>\n","protected":false},"author":27,"featured_media":11018,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[643,96,303],"type_dbi":[],"class_list":["post-11017","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oracle","tag-locks","tag-oracle","tag-result-cache"],"acf":[],"yoast_head":"\nResult cache invalidation caused by DML locks - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Result cache invalidation caused by DML locks\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . In a previous post about Result Cache, I was using ‘set autotrace on’ in my session to see when the result cache hit saves the logical reads. I got a comment, by e-mail and with full test case, mentioning that the invalidation I had when doing some DML does not occur […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2018-03-18T20:03:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1208\" \/>\n\t<meta property=\"og:image:height\" content=\"680\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"8 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Result cache invalidation caused by DML locks\",\"datePublished\":\"2018-03-18T20:03:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\"},\"wordCount\":829,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png\",\"keywords\":[\"Locks\",\"Oracle\",\"Result cache\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\",\"name\":\"Result cache invalidation caused by DML locks - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png\",\"datePublished\":\"2018-03-18T20:03:33+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png\",\"width\":1208,\"height\":680},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Result cache invalidation caused by DML locks\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Result cache invalidation caused by DML locks - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/","og_locale":"en_US","og_type":"article","og_title":"Result cache invalidation caused by DML locks","og_description":"By Franck Pachot . In a previous post about Result Cache, I was using ‘set autotrace on’ in my session to see when the result cache hit saves the logical reads. I got a comment, by e-mail and with full test case, mentioning that the invalidation I had when doing some DML does not occur […]","og_url":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/","og_site_name":"dbi Blog","article_published_time":"2018-03-18T20:03:33+00:00","og_image":[{"width":1208,"height":680,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png","type":"image\/png"}],"author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"8 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Result cache invalidation caused by DML locks","datePublished":"2018-03-18T20:03:33+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/"},"wordCount":829,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png","keywords":["Locks","Oracle","Result cache"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/","url":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/","name":"Result cache invalidation caused by DML locks - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png","datePublished":"2018-03-18T20:03:33+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/CaptureLocks.png","width":1208,"height":680},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/result-cache-invalidation-caused-by-dml-locks\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Result cache invalidation caused by DML locks"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11017","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=11017"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/11017\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/11018"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=11017"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=11017"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=11017"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=11017"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}