|
Re: efficient cascade delete [message #527040 is a reply to message #526210] |
Tue, 13 April 2010 19:32 |
|
If you use @PrivateOwned instead of cascade EclipseLink should optimize the deletion to avoid reading in the related objects. It will still read in B to delete the C's, but should not need to read C, unless C is using optimistic locking or has its own dependencies.
You could set the cascade on the constraint in the database instead of in JPA. This would mean that A would be removed from the cache, but not B or C. This might be ok, B and C should eventually garbage collect from the cache. The only way you could get B or C would be by a primary key query, if your app would never do this, then may be fine just leaving the cache as is. Otherwise you could invalidate the C and B caches.
James : Wiki : Book : Blog : Twitter
|
|
|
Powered by
FUDForum. Page generated in 0.04936 seconds