Smart update for bidirectional 1:n mapping?

Question

Hi,
when I add a new object to an 1:n mapping, it usually goes something like this
[Employee 1:n Phone]
// Phone Class
protected void setOwner(Employee emp) {
this.owner = emp;
// Employee Class
private List phones ;
public void addPhone(Phone phone) {
//important for db update
phone.setOwner(this);
//maintains correct object model
phones.add(phone);
If "phones" is an IndirectList and it hasn't yet been instantiated, then calling phones.add() will result in an SQL statement (select * from phones where ..) just to instantiate the list.
This can be performance problem for large n's so I sometimes use this trick:
public void addPhoneIfInstantiated(Phone phone) {
phone.setOwner(this);
if (phones instanceof IndirectContainer)
IndirectContainer indirectContainer = (IndirectContainer) phones;
if (indirectContainer.isInstantiated())
phones.add(phone);
It has however one major drawback: if "phones" is not instantiated when add is called and the application accesses it later, it will get instantiated without the new object as long as the unit of work remains uncommitted.
This problem would disappear if I were able flush the SQL to the database right after adding the new Phone object (start the transaction right away).
Is it posssible to do that in toplink 9.0.4? Will it be possible in the next release? I think ejb 3.0 requires something like this.
Or is there something else I can do to achieve the same result?
Ana

Answer 1

Hi,
The problem would not go away if you flushed the SQL, the hole would just be smaller.How would the hole be smaller?
What I meant is this:
If I send "insert .. into Phone" on a jdbc connection and then do a "select * from phone where employee_id=.." on the same connection, the result will include my uncommitted changes, won't it? The other connections won't see it but the current uow would be "conform" without the extra effort of in-memory querying.
I think however that the unit of work defers all reads to the client session, which in turn uses a different jdbc connection from a read-only pool. In that case flush won't help me at all.
>> There is nothing in 9.0.4, (or EJB3) that would handle this. I will log an enhancement request for this functionality.
That would be great!
If this is a major issue, they best solution is to not map the 1-m, then there is no issue. Instead the collection can be queried when required.The developers like their 1:m mapping and don't want to give it up :-).
The thing is, the same code is used both in an interactive application and in some batch jobs. In dialog mode it's OK to execute an sql query for the mapping, in batch mode not.
By the way, I tried the addToDescriptor approach but the valueholder doesn't contain the new object :-(.
Maybe I could write a Valueholder that works exactly like the IndirectList but doesn't trigger indirection on add. Instead it holds the added objects in an separate list and really adds them when/if the list is instantiated.
OK, it seems too much ado about nothing and I probably won't do it but do you think that it would work? Theoretically?
Ana