Bin Sun wrote:
Hi, David!
I'd like to share some of my ideas. We are
developing heavy stressed web applications based on
JDO. In each bi-di-relation, if the coder has to
assign both sides, the other side(usually a
collection) has to be loaded into memory and cause
much performance penalty. It's more efficient to leave
this synchronization task to the implementation.
Hi Bin,
Thanks for your sharing your experiences. This is what I was wanting -
a justification from a real live user!
But I have a quibble with your statement: "if the coder has to assign
both sides, the other side (usually a collection) has to be loaded into
memory".
So you're saying that if I have persistent objects just so:
public class Invoice {
private Set<Line> lines;
public void addLine(Line line) {
this.lines.add(line);
}
}
public class Line {
private Invoice invoice;
public void setInvoice(Invoice invoice) {
this.invoice = invoice;
}
}
and I do this:
static {
Invoice invoice = Util.getPersistentInvoice("1234");
Line line = new Line();
line.setInvoice(invoice):
invoice.addLine(line); /*expensive?*/
}
that the JDO impl necessarily fetches the entire contents of the
Invoice.lines collection? And *because* of this problem, you as a user
wish to avoid the invoice.addLine(line) call?
I guess there might be JDO impl's out there which do that. But I'd
rather pay money for a good one [1] which allowed me to control the
fetch policy. There's absolutely no reason why the JDO impl needs to go
to the database to let me invoke .add() on a SCO collection, until it
needs to flush and do an INSERT.
Hence there is no performance hit when setting both sides 'manually'.
Please hasten to correct me if I've misunderstood why the performance
hit takes place.
cheers,
David.
[1] Not that there are many takers for my money anymore since JSR 220
'took over' persistence.
