Hmm, so how are JTA+EJB working really? I mean we span a UserTransaction (JTA transaction), and an ejb joins that transaction. So it knows about the wrapping transaction. Maybe there's a method in JTA API to get the active transaction?
Ara. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:xdoclet-user- > [EMAIL PROTECTED]] On Behalf Of Colin Daly > Sent: Wednesday, July 17, 2002 10:02 AM > To: Vincent Harcq > Cc: xdoclet-user > Subject: Re: [Xdoclet-user] valueobject and bidirectional relationships > > good suggestion Vincent, > we've looked into this before (for dirty data object) > and there seemed to be no way to identify the transaction. > Do you think it would be worth requesting this functionality > be added to the 2.1 EJB spec. > > Colin > > On Wed, 2002-07-10 at 16:15, Vincent Harcq wrote: > > Hi, > > > > First, because an entity bean -must- run inside a transaction: > > Is there anyway to identify the running transaction ? I remember > > something like a JNDI lookup to java:/UserTransaction but this only > > works for BMT. Does something else exist to get access to the > > Transaction ID ? > > > > Then we can store this in the VO and simply return at the beginning of a > > VO getter if we are in the same transaction as the one saved in the VO. > > > > Second, I think the same problem occurs for CMP2 container vendors for > > bidirectionnal relationship. Of course they run inside the container so > > they have access to the Transaction. This is more simple. For > > MVCSoft that runs outside the container the problem is still there,..., > > except of course if it generate BMT BMP. Any thoughts are welcome here. > > > > Third, and the most important in fact ;). How would you solve your case > > if xdoclet did not exist ? > > > > Vincent. > > > > Colin Daly wrote: > > > > > > Hi all, > > > > > > i've been playing with the new value objects and i got quite excited > > > by the new (aggregate/compose) relationship handling (Excellent job > > > Vincent). We have quite a deep, complicated graph of value objects > which > > > we currently construct and deconstruct manually. The code is thousands > > > of lines long and is tedious, repetitive and error prone. The value > > > objects could blow away all of this except for one "little" problem. > > > They don't seem to handle bi-directional relationships. I tried it and > > > ended up with StackOverflowExceptions. > > > The problem is illustrated in the xdoclet samples themselves - > > > the following methods (getCustomerValue() and getAccountValue()) are > > > from the samples generated source files CustomerCMP and AccountCMP > > > respectively. There is a 1-N bidirectional aggregate relationship > > > between Customer and Account. As you can see, there is a problem. > > > Craig (a colleague) and I have had a chat about the problem and > > > there doesn't appear to be any quick fix. Hopefully this mail > > > will start a discussion and we will find a solution. > > > > > > Colin Daly. > > > > > > > > > > > > > > > > > > public test.interfaces.CustomerValue getCustomerValue() > > > { > > > if( CustomerValue == null ) > > > { > > > CustomerValue = new test.interfaces.CustomerValue(); > > > } > > > try > > > { > > > CustomerValue.setCredit( getCredit() ); > > > CustomerValue.setId( getId() ); > > > CustomerValue.setName( getName() ); > > > CustomerValue.setFirstName( getFirstName() ); > > > CustomerValue.setPhone( getPhone() ); > > > CustomerValue.setFax( getFax() ); > > > java.util.Iterator iAccountView = > getAccounts().iterator(); > > > while (iAccountView.hasNext()){ > > > -----> CustomerValue.addAccountView( > ((test.interfaces.AccountLocal)iAccountView.next()).getAccountValue() ); > > > | } > > > | CustomerValue.cleanAccountView(); > > > | java.util.Iterator iShippingAddressValue = > getShippingAddresses().iterator(); > > > | while (iShippingAddressValue.hasNext()){ > > > | CustomerValue.addShippingAddressValue( > ((test.interfaces.AddressLocal)iShippingAddressValue.next()).getAddressV al > ue() ); > > > | } > > > CustomerValue.cleanShippingAddressValue(); > > > S CustomerValue.setVersion(getVersion()); > > > T } > > > A catch (Exception e) > > > C { > > > K throw new javax.ejb.EJBException(e); > > > } > > > O return CustomerValue; > > > V } > > > E > > > R > > > F public test.interfaces.AccountValue getAccountValue() > > > L { > > > O if( AccountValue == null ) > > > W { > > > AccountValue = new test.interfaces.AccountValue(); > > > | } > > > | try > > > | { > > > | AccountValue.setBalance( getBalance() ); > > > | AccountValue.setId( getId() ); > > > | if ( getOwner() != null ) > > > -----> > AccountValue.setOwnerNormalValue(getOwner().getCustomerValue() ); > > > } > > > catch (Exception e) > > > { > > > throw new javax.ejb.EJBException(e); > > > } > > > return AccountValue; > > > } > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Stuff, things, and much much more. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Xdoclet-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
