OK, further context helps greatly.
By and large, JPA entity manager implementations assume that the
underlying connection is transactional (JTA or local). As a result,
although it is theoretically possible to use a non-transactional data
source with an entity manager it will probably lead to some of the
unpredictable behavior you are seeing - especially for complex enough cases.
I would honestly just leave the non-transactional flag alone. I am not
really sure what it's practical purpose in most Java EE applications
is/was. The only time I've ever seen that sort of thing in use is
non-JPA reporting applications (basically a set of big hairy hand
written SQL queries that are fairly independent of each other and don't
care about race conditions).
If you really want to find out what is going on I would turn up the JPA
log levels or examine the database log files. My guess is that because
the data source is non-transactional queries that the JPA provider is
issuing is not occurring in the order that it expects, resulting in
empty cursors under the hood - so basically a race condition due to lack
of proper atomicity/isolation.
On 7/11/2014 6:31 PM, Noah White wrote:
> On Jul 11, 2014, at 5:55 PM, Reza Rahman <Reza.Rahman_at_oracle.com> wrote:
>
>> Honestly I am having a hard time following what the problem is. Can you kindly outline the specific case you believe to be a bug?
> Not saying there is a bug, just trying to better understand things to determine if there is or is not. This stems from a real world issue I’ve been dealing with that is detailed here: http://stackoverflow.com/questions/24705651/inherited-entity-property-sometimes-is-null/24707549#24707549
>
> -Noah
>