Yet another possibility is that you may be reading uncommitted or
in-flight data since there is no isolation of any sort in a
non-transactional connection (vis-a-vis the auto-commit using data
source isolation level behavior you would normally get even without a
local or JTA transaction).
On 7/11/2014 6:57 PM, Reza Rahman wrote:
> 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
>>
>