Hi Vincent,
On Wed, 15 May 2002, Vincent Harcq wrote:
<snip>
> 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.
As I said before, we have a very complex swing app as our "web tier"
(doesn't anyone do swing programming anymore!), and the app modifies large
value object graphs. We have implemented a pessimistic coarse grained
locking strategy (in software), which guarantees that no one else can edit
that graph of dataobjects whilst locked. This seems like the nicest way
to edit large blocks of data on the client when you only have a small
number of users. It is critical in this scenario that there is no
instance duplication in the object graph. (e.g. one "DataObject/VO" per
primary key in this locked graph).
>
>
> > > 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
>
Yes, this is basically the problem, duplication within an object graph
(because of bi-directional or circular relationships)
> >
> > 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.
>
Excellent! I look forward to it.
Thanks,
Craig
_______________________________________________________________
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
