Hi, I posted this to the group a couple of weeks ago when trying to get 3.2.2RC1 working. Alex had a look at it and figured it was fixed for RC2. As RC2 was only a couple of weeks away I decided it'd be easier for me to wait for RC2 than build it, my mistake, I've just grabbed RC2 - it's still there. (I'll log a bug this time).
gavin
> -----Original Message-----
> From: Gavin Matthews
> Sent: Thursday, July 03, 2003 7:05 PM
> To: [EMAIL PROTECTED]
> Cc: '[EMAIL PROTECTED]'
> Subject: CMR Problem in 3.2.2?
>
>
> Hi,
> I posted yesterday and last week about a problem I was
> having with CMR when I upgraded from 3.2.0 to 3.2.2. I've
> done more investigation and I don't think my previous mails
> were entirely accurate (or very clear) so let me start over.
>
> The Problem:
> I'm experiencing NPE in our app because the CMR
> relationships are (apparently) not being created. This didn't
> occur with our app in 3.2.0.
>
> I have a sample case which I believe is representitive of
> the problem I'm seeing in our app. The beans are Foo & Bar
> (sorry about the naming). The relationship is N-Foo-1-Bar.
> The relation is being set in post create:
>
> public abstract class FooEJB extends AbstractEntityBean {
> ...
> public void ejbPostCreate(BarLocal bar, String fooValue)
> throws CreateException {
> sLog.debug("ejbPostCreate(" + getId() + ")");
>
> this.setBar(bar);
> }
> ...
> }
>
> And I have a test session which does the following:
>
> ...
> BarLocal bar = createBar("This is a bar");
> FooLocal foo = createFoo(bar, "This is a foo");
>
> sLog.info("****************************************");
> sLog.info("Bar id through foo: " + foo.getBar().getId());
> sLog.info("Bar id through bars foos: ");
>
> Collection foos = bar.getFoos();
> sLog.info("Number of foos associated with bar: "
> + foos.size());
>
> Iterator fooIter = bar.getFoos().iterator();
> while (fooIter.hasNext()) {
> FooLocal tmpFoo = (FooLocal) fooIter.next();
> sLog.info("Foo id: " + tmpFoo.getId());
> sLog.info("Bar id: " + tmpFoo.getBar().getId());
> }
> sLog.info("****************************************");
> ...
>
> I'd expect the output of this test case to be:
>
> 18:58:38,875 INFO [FooBarSessionEJB]
> ****************************************
> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through foo: 1011
> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through bars foos:
> 18:58:38,890 INFO [FooBarSessionEJB] Number of foos
> associated with bar: 1
> 18:58:38,906 INFO [FooBarSessionEJB] Foo id: 1017
> 18:58:38,906 INFO [FooBarSessionEJB] Bar id: 1011
> 18:58:38,906 INFO [FooBarSessionEJB]
> ****************************************
>
> What I'm actually seeing is:
>
> 18:58:38,875 INFO [FooBarSessionEJB]
> ****************************************
> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through foo: 1011
> 18:58:38,890 INFO [FooBarSessionEJB] Bar id through bars foos:
> 18:58:38,890 INFO [FooBarSessionEJB] Number of foos
> associated with bar: 0
> 18:58:38,906 INFO [FooBarSessionEJB]
> *******************************************
>
> If I add a finder call after the beans are created (which
> forces the beans to be synchronized to the database) then I
> get the results I expect. This makes me think that there's a
> problem with the caching - the "bar" returned by the
> create() call is not the same Bar instance as returned by
> foo.getBar(). Which means that I have 2 instances of the same
> bean within the same transaction which have different state -
> seems like a bug to me, I'd have expected the foo.getBar()
> call to return the same "bar" as was passed to the create() call.
>
> I've attached the source. For the sample, let me know what you think,
>
> thanks,
> gavin
>
FooEJB.java
Description: Binary data
FooBarSessionEJB.java
Description: Binary data
BarEJB.java
Description: Binary data
testSchema.sql
Description: Binary data
