I take a part of the message right now, I will reply on the rest in a few.
> > > - the new ValueObjects do NOT do null checking, creating new ones each
> > > getValueObject() call therefore two line items with the same product
> > > on the same order would have two different product value objects with
> > > the same primary key.
> > > This is bad for clients that need to CHANGE the value objects within
a
> > > graph of them. (i.e. the two product value objects would have
> > > different values)
> >
> > I agree maybe the object uniqueness is maybe not completely Ok or maybe
> > should I say "respect Pure Object Oriented way of doing". But...
> > I don't believe that in the case of 2 clients getting a instance of A
Value
> > Object MUST absolutely have the same Instance of it. The client do not
> > care about that but only about the VO.getPrimaryKey().equals() method
when
> > doing "isDentical" between VO.
>
> RMI's pass by value means that 2 clients will never get the same
> instance. We happen to have VERY complex object graphs going to the client
> (a "party" order for a multi level marketing company), and we must send
> the whole lot in one RMI batch to ensure that there is no object
> duplication. The reason for this is that the client edits this huge graph
> of objects and sends them back to "save". We really need to guarantee
> that dataObjects are not duplicated for the same entity (at least in the
> same transaction). (otherwise, how can the server tell which one is the
> correct one to save?)
You can not guarantee that because most of the time, VO will go to Web Tier,
so in 5 minutes ("user think time"), 2 users can get the same VO, if the 2
send the VO back to the entity bean to set it, you will face the Stale
problem. The last one will overwrite the changes the first one did.
Currently there is nothing to avoid that but it should not be difficult to
use the "version" attribute or other ways (comparing attributes per
attributes or ...). I plan to add some solutions for this problem. Ideas
are welcome.
So taking as hypothesis that the instance is the same is a bad idea imho.
The Entity can not tell what the client will do with the VO. The client can
even build a new one completely and send it back if he wants to.
> > We should also talk a bit about the MultiInstance approach of EJB
> > containers where for a specific PK, multiple instances of an EJB can
> > cohabit in the server. In this case it is simply impossible to give the
> > same instance of the VO to the 2 clients.
>
> Good point, although I would think that their would still only be one
> instance of an EJB PER TRANSACTION, so we would still be OK, and out of
> the transaction, RMI causes duplication anyhow (bye bye client lazy
> loading).
OK. I think now I misunderstood your point of view.
We agree on the "web client" way of doing so : 2 different instances.
In the same transaction, I see what you mean, let me think...
The problem is for birectionnal relationship. Is this is the case you talk
about ?
OrderValue <--> OrderLineValue
Then I can see your point... see later
>
> > >
> > >
> > > SOLUTION?
> > > ---------
> > > The third choice (IMHO the best) is to re "set" all the fields of the
> > > beans internal dataholder on EVERY call to getData/getValueObject.
> > > This avoids the dirtyness of the dataobject problem, and also the
> > > duplication possibility of the current ValueObject problem. The
server
> > > should never hold on to dataobjects BETWEEN TRANSACTIONS (except the
> > > "dataholder" inside the beans), because other threads inside the
server
> > > could call getData on one you are holding. Pass by value (RMI)
> > > protects you from this.
> > >
> >
> > With VO we introduce (Marcus could also talk about that) a "volatile"
> > attribute that do what DO do, this is when its value is set to "true"
> > (which is the default) resetting the entity cache of the VO to null in
> > ejbLoad(). So every clients will get its own VO instance.
> > Setting volatile to "false" (I think this is the (wrong) default on
XDoclet
> > 1.1.2) will not null the VO on ejbLoad, instead the getVO() will refresh
> > the entity instance's cache version of it.
> > I would not recommend using volatile="false", it will not provide a big
> > amount fo gain (99% of the time an entity is stuck in the JDBC calls).
>
> I had a look at the code a few weeks ago, and it seemed the getVO caused a
> "dataholder = new xxxVO();" so this means you get duplication, I think you
> could just call all the dataholder.set()s WITHOUT nulling it, and
> everything would be fixed.
OK. I think that is the correct solution. I will work on that when the
refactorng is finished.
>
> Craig
>
Vincent
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
Xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
