Hi Tom,
Agree with you. A clarification on my concepts may be helpful. As far as i know entity manager caching depends on type of entity manager
1- Extended, 2- transaction scoped.
For transaction scope, entity manager is opened and closed on transaction begin and commit, and in case of container managed transactions it is ejb method's start and end. So no caching in case of transaction scope entity manager, right?
Thanks
Regards,
Jehanzeb Qayyum
On Wed, Dec 23, 2009 at 7:58 PM, Tom Ware
<tom.ware@xxxxxxxxxx> wrote:
Hi jz,
In a JPA provider, there is more to doing a delete than just removing records from the database. As a minimum, any related objects need to be removed from the persistence context and for configurations that make use of caching, potentially other versions of the object need to be removed as well.
If you are using database-level cascade deletes, you will want to be sure to focus some of your testing on ensuring you get the expected behavior from the persistence context and from the cache after you do that kind of a delete.
Despite those reasons, there is probably an argument that a properly implemented database-level cascade delete could provide some performance benefits. Please feel free to enter an enhancement request.
-Tom
jz wrote:
Hi,
To remove an entity why does not EclipseLink support db level cascade delete? The schema generated does not contain on cascade delete on constraints. I have to manually change the sql script.
Regards,
Jehanzeb Qayyum
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users
