Hi Vincent, thanks for getting back to me so quickly! I am using JBoss too (currently 3.0.0_RC2, just ported across yesterday, whew!)
On Wed, 15 May 2002, Vincent Harcq wrote: <snip> > > > > - the current DataObjects will not ever refresh with commit option A > > because ejbLoad isn't called ever (after the initial load). i.e. they > > can get VERY dirty. > > ejbLoad must be called when the container decides to refresh the entit bean > state for any reasons. So with DO, ejbLoad sets it to null prior to > calling getData(). > With commit-option A, if the container decides to not ejbLoad() it is > because the state of the entity has not changed, so why "kill" the DO, it > has still the correct value. > To summarize a DO can only be dirty if the entity bean state change, and in > this case ejbLoad() must be called, so the Do is reset to null so no > problems. I believe this is incorrect, Commit Option A means that ejbLoad will not get called. It means that the container has EXCLUSIVE access to the database, so only ejbStores should happen. As the other guy reported in the bug report, this means that the data object never gets nulled. See section 10.9.5, figure 29 of the EJB2.0 spec (it clearly states that ejbLoad is not called with commit option A) > > > > > - 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?) > 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). > > > > > > 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. > > > BTW, when writing this email I checked the templates files and ejbLoad does > NOT refresh the VO, I was pretty sure it was OK there, I surely mess it up > at some point, Marcus can you have a look ? There is a > <XDtComment:comment> that avoid the entity-value-clean.j to be processed. > I don't have CVS access right now, I will see that tonight... > Again, I am pretty sure that with commit option A, ejbLoad is NOT called, so this is not an appropriate place to null the dataHolder IMHO. Regards, 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
