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

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
    234 Posts
    ACCEPTED ANSWER

    Re: Write-behind behavior

    ‏2012-06-21T10:13:02Z  in response to Erwin_Karbasi
    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
      ACCEPTED ANSWER

      Re: Write-behind behavior

      ‏2012-06-21T10:40:10Z  in response to jhanders
      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
        ACCEPTED ANSWER

        Re: Write-behind behavior

        ‏2012-06-27T05:46:53Z  in response to Erwin_Karbasi
        Hello All,

        You assistance would be highly appreciated.

        Thanks,
        Erwin
        • jhanders
          jhanders
          234 Posts
          ACCEPTED ANSWER

          Re: Write-behind behavior

          ‏2012-06-28T18:01:40Z  in response to Erwin_Karbasi
          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
            ACCEPTED ANSWER

            Re: Write-behind behavior

            ‏2012-11-20T18:53:59Z  in response to jhanders
            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
              ACCEPTED ANSWER

              Re: Write-behind behavior

              ‏2012-12-04T18:56:07Z  in response to Erwin_Karbasi
              Any help please!
            • SystemAdmin
              SystemAdmin
              1485 Posts
              ACCEPTED ANSWER

              Re: Write-behind behavior

              ‏2012-12-04T21:35:56Z  in response to Erwin_Karbasi
              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
                ACCEPTED ANSWER

                Re: Write-behind behavior

                ‏2012-12-04T23:53:48Z  in response to SystemAdmin
                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
                  ACCEPTED ANSWER

                  Re: Write-behind behavior

                  ‏2012-12-05T14:53:01Z  in response to Erwin_Karbasi
                  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
                    ACCEPTED ANSWER

                    Re: Write-behind behavior

                    ‏2012-12-06T23:31:58Z  in response to SystemAdmin
                    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.