[
https://issues.apache.org/jira/browse/METAMODEL-89?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14185946#comment-14185946
]
Michał Mela commented on METAMODEL-89:
--------------------------------------
Hi Kasper,
Thank you very much for your quick response! I totally agree with the
synchronized block solution idea not being too wasteful. However, I think it
would also be nice to rework the temp file name generation a bit so that there
is less potential iteration over already taken indices.
If, for example, there are already files between _metamodel0_ and
_metamodel1000_, it may take some time to roll the index part of the filename
to find a non-taken filename. I can think of two sample solutions:
* include {{InputStream}} object pointer reference (i.e. {{Object.hashcode()}}
return value for the CSV {{InputStream}} object) in the filename -- this would
make the need for rolling the index filename part very unlikely but I am not
sure if it would obviate the need for synchronized block to prevent the racing
condition
* include a
[UUID|http://docs.oracle.com/javase/7/docs/api/java/util/UUID.html] in the
filename -- this may replace both the index filename part as well as the
synchronized block for preventing the racing condition, but I am not sure if
generating a UUID is actually faster than it is to create a synchronized block
> Racing condition in CsvDataContext
> ----------------------------------
>
> Key: METAMODEL-89
> URL: https://issues.apache.org/jira/browse/METAMODEL-89
> Project: Metamodel
> Issue Type: Bug
> Affects Versions: 4.2.0-incubating
> Reporter: Michał Mela
>
> There seems to be a racing condition in the method that creates a temp file
> for CsvDataContexts constructed with an InputStream:
> CsvDataContext.createFileFromInputStream(InputStream inputStream, String
> encoding)
> For example, if in thread 1 we get to line 243 while in thread 2 we get to
> line 240, then, basically, in both threads we have made _sure_ that a file
> for *the same index in both of the threads* doesn't exist. Then both threads
> will use the same filename and one thread will overrride the data for another
> thread's tempfile.
> (the file line numbers were based on this listing:
> http://grepcode.com/file/repo1.maven.org/maven2/org.eobjects.metamodel/MetaModel-csv/3.4.11/org/eobjects/metamodel/csv/CsvDataContext.java#CsvDataContext)
> The immediate result is that in a thread whose tempfile was overwritten the
> data context will be created based on wrong data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
