Spring Batch
  1. Spring Batch
  2. BATCH-2018

TransactionAwareBufferedWriter uses hashcode as TransactionSynchronizationManager key

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: None
    • Fix Version/s: 3.0.0
    • Component/s: Infrastructure
    • Labels:
      None

      Description

      TransactionAwareBufferedWriter binds a StringBuffer to the current transaction:

      TransactionSynchronizationManager.bindResource(bufferKey, new StringBuffer());

      The bufferKey is computed as BUFFER_KEY_PREFIX + "." + hashCode();

      The hashCode of the TransactionAwareBufferedWriter is not guaranteed to be unique, so it's possible 2 writers end up writing to the same StringBuffer.

        Activity

        Hide
        Jimmy Praet added a comment -
        Show
        Jimmy Praet added a comment - pull request: https://github.com/SpringSource/spring-batch/pull/168
        Hide
        Michael Minella added a comment -

        While I will concede that this scenario is theoretically possible, the code in question has been battle tested for a very long time without anyone raising an issue (that I'm aware of). The unit tests in the PR do not demonstrate that the change prevents the issue (while a review of the code looks like it would). I would be very interested in hearing more about the scenario where this collision has been observed (OS/JRE distribution/etc). Per the contract of java.lang.Object#hashCode() (we haven't overridden hashCode() in any of the implementations in question), "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects". This would imply that the only way to raise the probability of a collision would be to reuse a MongoItemWriter or TransactionAwareBufferedWriter.

        For the record, I'm not arguing that the proposed change in the PR is bad...I just want a better understanding of where this request came from (under what conditions did this occur).

        Show
        Michael Minella added a comment - While I will concede that this scenario is theoretically possible, the code in question has been battle tested for a very long time without anyone raising an issue (that I'm aware of). The unit tests in the PR do not demonstrate that the change prevents the issue (while a review of the code looks like it would). I would be very interested in hearing more about the scenario where this collision has been observed (OS/JRE distribution/etc). Per the contract of java.lang.Object#hashCode() (we haven't overridden hashCode() in any of the implementations in question), "As much as is reasonably practical, the hashCode method defined by class Object does return distinct integers for distinct objects". This would imply that the only way to raise the probability of a collision would be to reuse a MongoItemWriter or TransactionAwareBufferedWriter. For the record, I'm not arguing that the proposed change in the PR is bad...I just want a better understanding of where this request came from (under what conditions did this occur).
        Hide
        Jimmy Praet added a comment -

        On my machine, without the proposed changes, the TransactionAwareBufferedWriterTests.testResourceKeyCollision test fails randomly with assertion errors such as:

        • org.junit.ComparisonFailure: expected:<13[]> but was:<13[4924]>
        • org.junit.ComparisonFailure: expected:<4[]> but was:<4[1700]>
        • org.junit.ComparisonFailure: expected:<7[]> but was:<7[3800]>

        OS: Microsoft Windows XP [Version 5.1.2600]

        I tested with both of these JRE's:

        java version "1.6.0"
        Java(TM) SE Runtime Environment (build pwi3260sr9fp1ifix-20110329_01(SR9 FP1+IZ95654+IZ91385+IZ95150))
        IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-201103
        24_78506 (JIT enabled, AOT enabled)
        J9VM - 20110324_078506
        JIT - r9_20101028_17488ifx3
        GC - 20101027_AA)
        JCL - 20110203_01

        java version "1.6.0_26"
        Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
        Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)

        Show
        Jimmy Praet added a comment - On my machine, without the proposed changes, the TransactionAwareBufferedWriterTests.testResourceKeyCollision test fails randomly with assertion errors such as: org.junit.ComparisonFailure: expected:<13[]> but was:<13 [4924] > org.junit.ComparisonFailure: expected:<4[]> but was:<4 [1700] > org.junit.ComparisonFailure: expected:<7[]> but was:<7 [3800] > OS: Microsoft Windows XP [Version 5.1.2600] I tested with both of these JRE's: java version "1.6.0" Java(TM) SE Runtime Environment (build pwi3260sr9fp1ifix-20110329_01(SR9 FP1+IZ95654+IZ91385+IZ95150)) IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Windows XP x86-32 jvmwi3260sr9-201103 24_78506 (JIT enabled, AOT enabled) J9VM - 20110324_078506 JIT - r9_20101028_17488ifx3 GC - 20101027_AA) JCL - 20110203_01 java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Client VM (build 20.1-b02, mixed mode, sharing)
        Hide
        Jimmy Praet added a comment -

        Can this fix also be included in the 2.2.2 release?

        Show
        Jimmy Praet added a comment - Can this fix also be included in the 2.2.2 release?

          People

          • Assignee:
            Michael Minella
            Reporter:
            Jimmy Praet
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: