An alternative to get rid of lock contention in Random() would be to use
ThreadLocalRandom -
https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ThreadLocalRandom.html


On Thursday, December 11, 2014, Gabriel Reid (JIRA) <[email protected]> wrote:

>
>     [
> https://issues.apache.org/jira/browse/PHOENIX-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14242481#comment-14242481
> ]
>
> Gabriel Reid commented on PHOENIX-1516:
> ---------------------------------------
>
> +1 to the idea of adding this kind of function.
>
> It seems ok to me that it isn't possible to set a random seed -- in my own
> use cases, setting a random seed is typically only useful for making sure
> that something is totally deterministic, but it seems like there are enough
> things going on all over the place (in different JVMs, different threads,
> etc), that it would be difficult to ensure that we have a fully
> deterministic random value coming out for each row.
>
> The fact that the same random will be generated for multiple columns in
> the same row seems like a bit of a show-stopper to me. As a user, I would
> expect that multiple calls to RANDOM() will give multiple (different)
> random values.
>
> One point that also is probably worth looking into is the creation of a
> new Random() in each call to evaluate(). The default constructor of
> Random() calls some code that has class-level locks, so there could be some
> lock contention if multiple threads in the same JVM are calling {{new
> Random()}} over and over.
>
> > Add RANDOM built-in function
> > ----------------------------
> >
> >                 Key: PHOENIX-1516
> >                 URL: https://issues.apache.org/jira/browse/PHOENIX-1516
> >             Project: Phoenix
> >          Issue Type: Bug
> >            Reporter: Lars Hofhansl
> >            Assignee: Lars Hofhansl
> >         Attachments: 1516.txt
> >
> >
> > I often find it useful to generate some rows with random data.
> > Here's a simple RANDOM() function that we could use for that.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v6.3.4#6332)
>

Reply via email to