To get an instance of A the EntityManager.find() method is used. This returns an instance of A. Now
the list is processed using a for-each loop.
for ( B bElement : list ) {
// do something with bElement
}

Sometimes one of the elements in the list is null. If this is the case I have checked the following:
- Logged size of the list (e.g. 30)
- Checked database. The database contains 30 valid entries which should be in the list.
- The last element in the list was null.
- The last element was added in the previous transaction.

The strange thing is that it is working when turning the shared cache off, so I suspect that this is a bug.

In the meantime we have also tested this with EclipseLink 2.2-M6 and Glassfish 3.1 but the error still appears.

Any help is much appreciated since the disabled cache leads to a performance drop of about 35% for our application. We would not like to implement a caching concept or introduce some ordering concept of our own to work around this bug since this would mean to change the code in very much locations. Let alone the necessary effort to test the whole thing thoroughly afterwards.

Please file a bug with a test case that can reproduce the issue. The simpler the test case the better.

As for workarounds, an alternative is to refresh the Image object. This might also have to do with change tracking, so another option might be to try different change tracking options as described here:http://wiki.eclipse.org/Using_EclipseLink_JPA_Extensions_ (ELUG)#Using_EclipseLink_JPA_Extensions_for_Tracking_Changes
This will also help narrow down the problem if you determine one of the settings shows the problem but others do not.

That reference is out of context, and is not a warning that orderby does not work. It is a warning that the objects read in might come from the cache, but the @OrderBy only applies when the collection is read in from the database - essentially stating that the JPA provider does not maintain the list order for you. So if you make changes to the list, the next time you read the owner, you may see the list in the same order as you left it in - depending on if the object was in the cache or if it had to be built/refreshed from the database since your changes were made.

There was a problem with nulls, but is was a specific situation involving attribute change tracking and merging that does not seem to be occuring here. As your attempt to reproduce shows, it is not a common situation, or one that we have seen before (that I am aware of) and likely a product of a specific set of conditions in your application. As the last issue I was aware of dealt with change tracking, I figure that is a good place to start in isolating the issue though it is difficult to guess.