WebSphere Application Server - Entity ejbRemove, with Foreign Key Dependancies, in a Tranaction

This is Interesting: Free IT Magazines  
Home > Archive > WebSphere Application Server > September 2005 > Entity ejbRemove, with Foreign Key Dependancies, in a Tranaction





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Entity ejbRemove, with Foreign Key Dependancies, in a Tranaction
c_koell

2005-09-19, 7:50 am

In a transaction the database updates (ejbStore() calls) occur at the end of the transaction, and occur in the order the updates were called. Clearly the order in which the updates occur must be maintained due to possible referential integrity constraints
within the DB.

My current problem is that calls to remove() result in an immediate call to ejbRemove(), which causes an out-of-order operation with some updates that occurred within the same TX.

My tables are structured like the following (just an example):

EMPLOYEE:
__________________________
| EMPLOYEE_PK | MANAGER_FK |
+-------------+------------+
| E1 | M3 |
| E2 | M3 |O---+
| E3 | M4 | |
| E4 | M4 | |
-------------------------- |
|
MANAGER: |
____________ |
| MANAGER_PK | |
+------------+ |
| M3 |------------------+
| M4 |
------------



Now if I want to delete M3 I need to clear the MANAGER_FK field in the appropriate EMPLOYEE records. For example:


1 String managerToDeleteId = "M3";
2
3 Collection c = EmployeeHome.findByManager(managerToDeleteId);
4 Iterator i = c.iterator();
5 while(i.hasNext())
6 {
7 Employee e = (Employee)c.next();
8 e.setManagerID(null);
9 }
10
11 Manager m = ManagerHomd.findByPrimaryKey(managerToDeleteId);
12 m.remove();



To my mind this should work just fine, but when the code is run the removal of the manager (via ejbRemove()) is called immediately, thus since ejbStore() for the Employees has not yet been called (waiting for the end of the TX) a foreign key constraint is
violated and a SQLException is thrown.


We have an alternative table structure which could avoid the issue (by using an association table, and putting control of it under the Manager) but we feel that is inappropriate.

Any suggestions?
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com