You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by "Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com> on 2017/04/26 02:05:01 UTC
CacheAbstractJdbcStore batch deleteAll bug.
Hi Guys,
I think there is a problem in CacheAbstractJdbcStore.deleteAll
I find that sometimes, I see messages like this
[DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey, cnt=2]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
Note the entity types are different!
Also look at the attached image. You can see the statement is still targeting Trade, but our entity is now Position.
You can see in the code, that the delStmt never gets refreshed, when changing over to a different entity type.
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
}
I believe should be something like this
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
delStmt = conn.prepareStatement(em.remQry);
}
Thanks,
Gordon.
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
RE: CacheAbstractJdbcStore batch deleteAll bug.
Posted by "Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com>.
Thanks Alexey,
No that’s okay, I am not a contributor. Please go ahead.
From: Alexey Kuznetsov [mailto:akuznetsov@apache.org]
Sent: Thursday, 11 May 2017 4:51 PM
To: user@ignite.apache.org
Subject: Re: CacheAbstractJdbcStore batch deleteAll bug.
Gordon,
I created https://issues.apache.org/jira/browse/IGNITE-5199
Would you like to contribute fix for that bug?
On Thu, May 11, 2017 at 12:43 PM, Gordon Reid (Nine Mile) <go...@ninemilefinancial.com>> wrote:
Sorry, I don’t have time to produce a sample right now, but I can see that this bug still exists in ignite 2.0
Just look in CacheAbstractJdbcStore.deleteAll
You can see that delStmt never gets updated after it is first initialized
Thanks,
Gordon.
From: Alexey Kuznetsov [mailto:akuznetsov@apache.org<ma...@apache.org>]
Sent: Thursday, 27 April 2017 6:50 PM
To: user@ignite.apache.org<ma...@ignite.apache.org>
Subject: Re: CacheAbstractJdbcStore batch deleteAll bug.
Hi, Gordon.
Do you have a reproducer we could debug?
Thanks.
On Wed, Apr 26, 2017 at 9:50 AM, Gordon Reid (Nine Mile) <go...@ninemilefinancial.com>> wrote:
Actually the fix will be a little more complicated, because the variable “em” has already been updated to the new type before the last batch has been executed.
From: Gordon Reid (Nine Mile) [mailto:gordon.reid@ninemilefinancial.com<ma...@ninemilefinancial.com>]
Sent: Wednesday, 26 April 2017 12:05 PM
To: user@ignite.apache.org<ma...@ignite.apache.org>
Subject: CacheAbstractJdbcStore batch deleteAll bug.
Hi Guys,
I think there is a problem in CacheAbstractJdbcStore.deleteAll
I find that sometimes, I see messages like this
[DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey, cnt=2]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
Note the entity types are different!
Also look at the attached image. You can see the statement is still targeting Trade, but our entity is now Position.
You can see in the code, that the delStmt never gets refreshed, when changing over to a different entity type.
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
}
I believe should be something like this
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
delStmt = conn.prepareStatement(em.remQry);
}
Thanks,
Gordon.
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
--
Alexey Kuznetsov
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
--
Alexey Kuznetsov
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
Re: CacheAbstractJdbcStore batch deleteAll bug.
Posted by Alexey Kuznetsov <ak...@apache.org>.
Gordon,
I created https://issues.apache.org/jira/browse/IGNITE-5199
Would you like to contribute fix for that bug?
On Thu, May 11, 2017 at 12:43 PM, Gordon Reid (Nine Mile) <
gordon.reid@ninemilefinancial.com> wrote:
> Sorry, I don’t have time to produce a sample right now, but I can see that
> this bug still exists in ignite 2.0
>
>
>
> Just look in CacheAbstractJdbcStore.deleteAll
>
>
>
> You can see that delStmt never gets updated after it is first initialized
>
>
>
> Thanks,
>
> Gordon.
>
>
>
> *From:* Alexey Kuznetsov [mailto:akuznetsov@apache.org]
> *Sent:* Thursday, 27 April 2017 6:50 PM
> *To:* user@ignite.apache.org
> *Subject:* Re: CacheAbstractJdbcStore batch deleteAll bug.
>
>
>
> Hi, Gordon.
>
>
>
> Do you have a reproducer we could debug?
>
>
>
> Thanks.
>
>
>
> On Wed, Apr 26, 2017 at 9:50 AM, Gordon Reid (Nine Mile) <gordon.reid@
> ninemilefinancial.com> wrote:
>
> Actually the fix will be a little more complicated, because the variable
> “em” has already been updated to the new type before the last batch has
> been executed.
>
>
>
> *From:* Gordon Reid (Nine Mile) [mailto:gordon.reid@ninemilefinancial.com]
>
> *Sent:* Wednesday, 26 April 2017 12:05 PM
> *To:* user@ignite.apache.org
> *Subject:* CacheAbstractJdbcStore batch deleteAll bug.
>
>
>
> Hi Guys,
>
>
>
> I think there is a problem in CacheAbstractJdbcStore.deleteAll
>
>
>
> I find that sometimes, I see messages like this
>
>
>
> [DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey,
> cnt=2]
>
> [WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Batch deleteAll returned unexpected updated row count [table=public.
> nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
>
> [WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Batch deleteAll returned unexpected updated row count
> [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
>
>
>
> Note the entity types are different!
>
>
>
> Also look at the attached image. You can see the statement is still
> targeting Trade, but our entity is now Position.
>
>
>
> You can see in the code, that the delStmt never gets refreshed, when
> changing over to a different entity type.
>
>
>
> for (Object key : keys) {
> Object keyTypeId = typeIdForObject(key);
>
> em = entryMapping(cacheName, keyTypeId);
>
> if (delStmt == null) {
> delStmt = conn.prepareStatement(em.remQry);
>
> currKeyTypeId = keyTypeId;
> }
>
> if (!currKeyTypeId.equals(keyTypeId)) {
> if (log.isDebugEnabled())
> log.debug("Delete entries from db [cache=" + U.*maskName*(cacheName) +
> ", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
>
> executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
>
> fromIdx += prepared;
>
> prepared = 0;
>
> currKeyTypeId = keyTypeId;
>
> }
>
>
>
>
>
> I believe should be something like this
>
>
>
> for (Object key : keys) {
> Object keyTypeId = typeIdForObject(key);
>
> em = entryMapping(cacheName, keyTypeId);
>
> if (delStmt == null) {
> delStmt = conn.prepareStatement(em.remQry);
>
> currKeyTypeId = keyTypeId;
> }
>
> if (!currKeyTypeId.equals(keyTypeId)) {
> if (log.isDebugEnabled())
> log.debug("Delete entries from db [cache=" + U.*maskName*(cacheName) +
> ", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
>
> executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
>
> fromIdx += prepared;
>
> prepared = 0;
>
> currKeyTypeId = keyTypeId;
>
> delStmt = conn.prepareStatement(em.remQry);
> }
>
>
>
> Thanks,
>
> Gordon.
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
>
>
>
>
> --
>
> Alexey Kuznetsov
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
--
Alexey Kuznetsov
RE: CacheAbstractJdbcStore batch deleteAll bug.
Posted by "Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com>.
Sorry, I don’t have time to produce a sample right now, but I can see that this bug still exists in ignite 2.0
Just look in CacheAbstractJdbcStore.deleteAll
You can see that delStmt never gets updated after it is first initialized
Thanks,
Gordon.
From: Alexey Kuznetsov [mailto:akuznetsov@apache.org]
Sent: Thursday, 27 April 2017 6:50 PM
To: user@ignite.apache.org
Subject: Re: CacheAbstractJdbcStore batch deleteAll bug.
Hi, Gordon.
Do you have a reproducer we could debug?
Thanks.
On Wed, Apr 26, 2017 at 9:50 AM, Gordon Reid (Nine Mile) <go...@ninemilefinancial.com>> wrote:
Actually the fix will be a little more complicated, because the variable “em” has already been updated to the new type before the last batch has been executed.
From: Gordon Reid (Nine Mile) [mailto:gordon.reid@ninemilefinancial.com<ma...@ninemilefinancial.com>]
Sent: Wednesday, 26 April 2017 12:05 PM
To: user@ignite.apache.org<ma...@ignite.apache.org>
Subject: CacheAbstractJdbcStore batch deleteAll bug.
Hi Guys,
I think there is a problem in CacheAbstractJdbcStore.deleteAll
I find that sometimes, I see messages like this
[DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey, cnt=2]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
Note the entity types are different!
Also look at the attached image. You can see the statement is still targeting Trade, but our entity is now Position.
You can see in the code, that the delStmt never gets refreshed, when changing over to a different entity type.
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
}
I believe should be something like this
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
delStmt = conn.prepareStatement(em.remQry);
}
Thanks,
Gordon.
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
--
Alexey Kuznetsov
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
Re: CacheAbstractJdbcStore batch deleteAll bug.
Posted by Alexey Kuznetsov <ak...@apache.org>.
Hi, Gordon.
Do you have a reproducer we could debug?
Thanks.
On Wed, Apr 26, 2017 at 9:50 AM, Gordon Reid (Nine Mile) <
gordon.reid@ninemilefinancial.com> wrote:
> Actually the fix will be a little more complicated, because the variable
> “em” has already been updated to the new type before the last batch has
> been executed.
>
>
>
> *From:* Gordon Reid (Nine Mile) [mailto:gordon.reid@ninemilefinancial.com]
>
> *Sent:* Wednesday, 26 April 2017 12:05 PM
> *To:* user@ignite.apache.org
> *Subject:* CacheAbstractJdbcStore batch deleteAll bug.
>
>
>
> Hi Guys,
>
>
>
> I think there is a problem in CacheAbstractJdbcStore.deleteAll
>
>
>
> I find that sometimes, I see messages like this
>
>
>
> [DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey,
> cnt=2]
>
> [WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Batch deleteAll returned unexpected updated row count [table=public.
> nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
>
> [WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore -
> Batch deleteAll returned unexpected updated row count
> [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
>
>
>
> Note the entity types are different!
>
>
>
> Also look at the attached image. You can see the statement is still
> targeting Trade, but our entity is now Position.
>
>
>
> You can see in the code, that the delStmt never gets refreshed, when
> changing over to a different entity type.
>
>
>
> for (Object key : keys) {
> Object keyTypeId = typeIdForObject(key);
>
> em = entryMapping(cacheName, keyTypeId);
>
> if (delStmt == null) {
> delStmt = conn.prepareStatement(em.remQry);
>
> currKeyTypeId = keyTypeId;
> }
>
> if (!currKeyTypeId.equals(keyTypeId)) {
> if (log.isDebugEnabled())
> log.debug("Delete entries from db [cache=" + U.*maskName*(cacheName) +
> ", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
>
> executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
>
> fromIdx += prepared;
>
> prepared = 0;
>
> currKeyTypeId = keyTypeId;
>
> }
>
>
>
>
>
> I believe should be something like this
>
>
>
> for (Object key : keys) {
> Object keyTypeId = typeIdForObject(key);
>
> em = entryMapping(cacheName, keyTypeId);
>
> if (delStmt == null) {
> delStmt = conn.prepareStatement(em.remQry);
>
> currKeyTypeId = keyTypeId;
> }
>
> if (!currKeyTypeId.equals(keyTypeId)) {
> if (log.isDebugEnabled())
> log.debug("Delete entries from db [cache=" + U.*maskName*(cacheName) +
> ", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
>
> executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
>
> fromIdx += prepared;
>
> prepared = 0;
>
> currKeyTypeId = keyTypeId;
>
> delStmt = conn.prepareStatement(em.remQry);
> }
>
>
>
> Thanks,
>
> Gordon.
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
>
>
>
>
> This email and any attachments are proprietary & confidential and are
> intended solely for the use of the individuals to whom it is addressed. Any
> views or opinions expressed are solely for those of the author and do not
> necessarily reflect those of Nine Mile Financial Pty. Limited. If you have
> received this email in error, please let us know immediately by reply email
> and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346
> 1349 0252
>
--
Alexey Kuznetsov
RE: CacheAbstractJdbcStore batch deleteAll bug.
Posted by "Gordon Reid (Nine Mile)" <go...@ninemilefinancial.com>.
Actually the fix will be a little more complicated, because the variable "em" has already been updated to the new type before the last batch has been executed.
From: Gordon Reid (Nine Mile) [mailto:gordon.reid@ninemilefinancial.com]
Sent: Wednesday, 26 April 2017 12:05 PM
To: user@ignite.apache.org
Subject: CacheAbstractJdbcStore batch deleteAll bug.
Hi Guys,
I think there is a problem in CacheAbstractJdbcStore.deleteAll
I find that sometimes, I see messages like this
[DEBUG] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Delete entries from db [cache=D9Cache, keyType=com.nmf.model.trading.TradeKey, cnt=2]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=1], expected=1, actual=0]
[WARN ] 2017-04-26 11:08:54.097 [flusher-0-#31%null%] CacheJdbcPojoStore - Batch deleteAll returned unexpected updated row count [table=public.nmfctrade, entry=RiskRuleKey [id=2], expected=1, actual=0]
Note the entity types are different!
Also look at the attached image. You can see the statement is still targeting Trade, but our entity is now Position.
You can see in the code, that the delStmt never gets refreshed, when changing over to a different entity type.
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
}
I believe should be something like this
for (Object key : keys) {
Object keyTypeId = typeIdForObject(key);
em = entryMapping(cacheName, keyTypeId);
if (delStmt == null) {
delStmt = conn.prepareStatement(em.remQry);
currKeyTypeId = keyTypeId;
}
if (!currKeyTypeId.equals(keyTypeId)) {
if (log.isDebugEnabled())
log.debug("Delete entries from db [cache=" + U.maskName(cacheName) +
", keyType=" + em.keyType() + ", cnt=" + prepared + "]");
executeBatch(em, delStmt, "deleteAll", fromIdx, prepared, lazyKeys);
fromIdx += prepared;
prepared = 0;
currKeyTypeId = keyTypeId;
delStmt = conn.prepareStatement(em.remQry);
}
Thanks,
Gordon.
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252
This email and any attachments are proprietary & confidential and are intended solely for the use of the individuals to whom it is addressed. Any views or opinions expressed are solely for those of the author and do not necessarily reflect those of Nine Mile Financial Pty. Limited. If you have received this email in error, please let us know immediately by reply email and delete from your system. Nine Mile Financial Pty. Limited. ABN: 346 1349 0252