| OneToMany list contains null entries when using OrderBy and shared cache [message #661117] |
Wed, 23 March 2011 05:14  |
Eclipse User |
|
|
|
Hi,
we have a problem in our software when using EclipseLink with a OneToMany relationship. A colleague of mine already posted to the Glassfish forum some time ago:
http://www.java.net/forum/topic/glassfish/glassfish/gf-v3-ec lipselink-onetomany-list-contains-null-entries
| Quote: |
@Entity
public class A {
@OneToMany( mappedBy="aInstance" )
@OrderBy( "someId" )
private List<B> list = new ArrayList<B>();
}
@Entity
public class B {
@ManyToOne
@JoinColumn( name="id" )
private A aInstance;
}
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.
|
Another post we have found here: http://www.theserverside.com/discussions/thread.tss?thread_i d=60269
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.
Best regards and thanks in advance,
Chris
|
|
|
|
|
| Re: OneToMany list contains null entries when using OrderBy and shared cache [message #661394 is a reply to message #661321] |
Thu, 24 March 2011 09:58  |
| Eclipse User |
|
|
|
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.
Best Regards,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.04246 seconds
Home