OK,
Then reset the VO to NULL at the end of transaction and don't recreate
it if it is <> NULL in the getter.
"end of transaction" could be very roughly translated by ejbStore().
And...
We come back to what Data Objects did in ejbdoclet at the beginning ;)
We may see the come back of the problem of 1:n bidirectionnal
relationships where the "reverse" link point to another VO instance that
the "direct" link... in the case ejbStore is called multiple times in
the Tx, what the spec permit I think.
I will need to review the spec carefully to be 100% sure of what I told.
Colin Daly wrote:
> 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.
>
I believe there are good reasons why we can not have that. That makes a
long time I would love to have this Tx object to be able to store
"context" stuffs in it that I can get back in the my "chains" of calls.
> Colin
>
Vincent
> 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()).getAddressValue() );
>>> | }
>>> 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
