[
https://issues.apache.org/jira/browse/OPENJPA-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12728994#action_12728994
]
Michael Dick commented on OPENJPA-1168:
---------------------------------------
Hi Rick,
I'm unable to hit the timing window you mention on my system, but your
explanation is sound.
That said there's still a window where IP can be initialized (non null) but not
copied. Another thread could hit this window when IP was empty and get a
non-unique id. It's probably safer to set a different flag at the end of the
method and key off that instead of IP or RANDOM.
Thanks for the patch though - I doubt this was easy to find.
> NPE in UUIDGenerator.initializeForType1()
> -----------------------------------------
>
> Key: OPENJPA-1168
> URL: https://issues.apache.org/jira/browse/OPENJPA-1168
> Project: OpenJPA
> Issue Type: Bug
> Components: lib
> Reporter: Rick Curtis
> Fix For: 1.3.0, 2.0.0
>
> Attachments: OPENJPA-1168.patch
>
>
> When UUIDGenerator.createType1() is called by more than one thread at
> *nearly* the same time AND UUIDGenerator.createType1() wasn't called
> previously, a small timing window exists where a NPE will result.
> Scenario:
> Thread 1 calls UUIDGenerator.createType1() and RANDOM == null so
> initializeForType1() is called. While that thread is in initializeForType1(),
> it sets the static variable RANDOM so that value is no longer null. Now
> Thread 2 calls UUIDGenerator.createType1() and RANDOM is no longer null, so
> it proceeds to the call System.arraycopy(IP, 0, uuid, 10, IP.length);. At
> this point Thread 1 hasn't got to initializing IP yet, so Thread 2 gets hits
> a NPE.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
