Topic
  • 10 replies
  • Latest Post - ‏2012-12-06T23:31:58Z by Erwin_Karbasi
Erwin_Karbasi
Erwin_Karbasi
186 Posts

Pinned topic Write-behind behavior

‏2012-06-21T10:08:14Z |
Hello Masters,

I have one concept question about write-behind feature.
If we have defined write-behind and the transaction to the back-end (i.e. database) failed, whether the BackingMap would invoke rollback to data that exist in the map.

We have seen that if the transaction to the database is failed the data that inserted into the map was removed.

I didn't find any direction about this behavior of write-behind in the documentation.

You assistance would be highly appreciated,
Erwin
Updated on 2012-12-06T23:31:58Z at 2012-12-06T23:31:58Z by Erwin_Karbasi
  • jhanders
    jhanders
    261 Posts

    Re: Write-behind behavior

    ‏2012-06-21T10:13:02Z  
    Erwin,

    You are correct. Since the transaction failed, we need to invalidate the entry in the grid since it doesn't match what is in the database due to the failure to update the database. The key is put into the failed updates map and you need to poll that map so as to do the right action for the failure for your application.

    I hope that helps.

    Jared Anderson
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-06-21T10:40:10Z  
    • jhanders
    • ‏2012-06-21T10:13:02Z
    Erwin,

    You are correct. Since the transaction failed, we need to invalidate the entry in the grid since it doesn't match what is in the database due to the failure to update the database. The key is put into the failed updates map and you need to poll that map so as to do the right action for the failure for your application.

    I hope that helps.

    Jared Anderson
    Hello Jared,

    Thank you a lot for update.

    Is it possible to prevent the grid from automatic invalidate the entry.
    Perhaps i don't want to invalidate and remove the entry from grid but retry to insert the entry to the database.

    Thanks,
    Erwin
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-06-27T05:46:53Z  
    Hello Jared,

    Thank you a lot for update.

    Is it possible to prevent the grid from automatic invalidate the entry.
    Perhaps i don't want to invalidate and remove the entry from grid but retry to insert the entry to the database.

    Thanks,
    Erwin
    Hello All,

    You assistance would be highly appreciated.

    Thanks,
    Erwin
  • jhanders
    jhanders
    261 Posts

    Re: Write-behind behavior

    ‏2012-06-28T18:01:40Z  
    Hello All,

    You assistance would be highly appreciated.

    Thanks,
    Erwin
    Erwin,

    The goal of write behind is to make sure that the database gets updated with what is in grid. If the database update fails, then the grid cannot keep the updated value since it would cause inconsistency. Since we do the invalidation, the next time that entry is fetched it will be fetched from the database so that we maintain consistency between the grid and database. In order to maintain consistency the only thing we could do instead of an invalidation is to put the database entry back into the grid so that the grid had the database entry immediately instead of having to fetch it later. We do not have that function with write behind today.

    It sounds like if you want the grid to not invalidate, you want to have a write through cache or a side cache configuration so you have control on the state of the grid.

    I hope that helps answer your question.

    Jared Anderson
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-11-20T18:53:59Z  
    • jhanders
    • ‏2012-06-28T18:01:40Z
    Erwin,

    The goal of write behind is to make sure that the database gets updated with what is in grid. If the database update fails, then the grid cannot keep the updated value since it would cause inconsistency. Since we do the invalidation, the next time that entry is fetched it will be fetched from the database so that we maintain consistency between the grid and database. In order to maintain consistency the only thing we could do instead of an invalidation is to put the database entry back into the grid so that the grid had the database entry immediately instead of having to fetch it later. We do not have that function with write behind today.

    It sounds like if you want the grid to not invalidate, you want to have a write through cache or a side cache configuration so you have control on the state of the grid.

    I hope that helps answer your question.

    Jared Anderson
    Hello Jared,

    Thank you a lot for information.

    We'd like to use the write-behind mechanize to lower the latency of insert operation to the cache, but we also want to prevent the invalidation of data from cache when the transaction to database failed.

    Is there any type of Exception thrown when the transaction to the database failed, so I could catch this exception to avoid the invalidation of data from cache and try to insert the inconsistent data into database later.

    Your insight regarding how to avoid the invalidation of data from cache after the write behind failed would be appreciated.

    Thank you in advance,
    Erwin
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-12-04T18:56:07Z  
    Hello Jared,

    Thank you a lot for information.

    We'd like to use the write-behind mechanize to lower the latency of insert operation to the cache, but we also want to prevent the invalidation of data from cache when the transaction to database failed.

    Is there any type of Exception thrown when the transaction to the database failed, so I could catch this exception to avoid the invalidation of data from cache and try to insert the inconsistent data into database later.

    Your insight regarding how to avoid the invalidation of data from cache after the write behind failed would be appreciated.

    Thank you in advance,
    Erwin
    Any help please!
  • SystemAdmin
    SystemAdmin
    1485 Posts

    Re: Write-behind behavior

    ‏2012-12-04T21:35:56Z  
    Hello Jared,

    Thank you a lot for information.

    We'd like to use the write-behind mechanize to lower the latency of insert operation to the cache, but we also want to prevent the invalidation of data from cache when the transaction to database failed.

    Is there any type of Exception thrown when the transaction to the database failed, so I could catch this exception to avoid the invalidation of data from cache and try to insert the inconsistent data into database later.

    Your insight regarding how to avoid the invalidation of data from cache after the write behind failed would be appreciated.

    Thank you in advance,
    Erwin
    That invalidation is something the product doesn't let you disable. In the case of the error, we want
    to ensure consistency.
    You could write your own loader that would handle DB exception scenarios and take different actions.

    The update that failed to be sent to the DB is in the failed update map, you may want to monitor this map
    and correct the inserts to the database and let the grid stay consistent with what's in the DB.

    Here's an example:
    http://pic.dhe.ibm.com/infocenter/wxsinfo/v8r6/topic/com.ibm.websphere.extremescale.doc/cxsfailupdate.html
    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-12-04T23:53:48Z  
    That invalidation is something the product doesn't let you disable. In the case of the error, we want
    to ensure consistency.
    You could write your own loader that would handle DB exception scenarios and take different actions.

    The update that failed to be sent to the DB is in the failed update map, you may want to monitor this map
    and correct the inserts to the database and let the grid stay consistent with what's in the DB.

    Here's an example:
    http://pic.dhe.ibm.com/infocenter/wxsinfo/v8r6/topic/com.ibm.websphere.extremescale.doc/cxsfailupdate.html
    Fred
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
    Hello Fred,

    Thanks a lot for your direction.

    As you pointed out: "That invalidation is something the product doesn't let you disable. In the case of the error, we want
    to ensure consistency.
    You could write your own loader that would handle DB exception scenarios and take different actions."

    Sorry for misunderstanding, there is not any way to disable the invalidation even if I'll write custom loader and handle DB exceptions and prevent the exception from getting to the cache?

    Thanks,
    Erwin
  • SystemAdmin
    SystemAdmin
    1485 Posts

    Re: Write-behind behavior

    ‏2012-12-05T14:53:01Z  
    Hello Fred,

    Thanks a lot for your direction.

    As you pointed out: "That invalidation is something the product doesn't let you disable. In the case of the error, we want
    to ensure consistency.
    You could write your own loader that would handle DB exception scenarios and take different actions."

    Sorry for misunderstanding, there is not any way to disable the invalidation even if I'll write custom loader and handle DB exceptions and prevent the exception from getting to the cache?

    Thanks,
    Erwin
    Hey Erwin, No problem.
    If you write your own loader, you can handle the exception in the loader directly, and instead of throwing a DB exception back to the framework indicating the failure, you can catch it right at the time it occurs and decide what to do.

    When you configure writebehind, the grid uses a writebehind loader that acts as an asynchronous batching and proxy to the loader that is configured for the grid, so the ultimate DB responsibility is still delegated to the configured loader.

    Ultimately, you would have to come up with a strategy like the writebehind loader does and store the failures persistently so the data doesn't get lost or inconsistent with the DB.
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
  • Erwin_Karbasi
    Erwin_Karbasi
    186 Posts

    Re: Write-behind behavior

    ‏2012-12-06T23:31:58Z  
    Hey Erwin, No problem.
    If you write your own loader, you can handle the exception in the loader directly, and instead of throwing a DB exception back to the framework indicating the failure, you can catch it right at the time it occurs and decide what to do.

    When you configure writebehind, the grid uses a writebehind loader that acts as an asynchronous batching and proxy to the loader that is configured for the grid, so the ultimate DB responsibility is still delegated to the configured loader.

    Ultimately, you would have to come up with a strategy like the writebehind loader does and store the failures persistently so the data doesn't get lost or inconsistent with the DB.
    "Leaders are visionaries with a poorly developed sense of fear and no concept of the odds against them." Robert Jarvik
    Thank you a lot for clarification.

    We'll try to handle exceptions in our custom loader in order the grid will not invalidate the data from cache if the operation on database failed.