Hi,
I personally don't see anything wrong with this, but I am not an expert.
Note that you have 2 separate transactions here, the first one readig the
customer data, the second rereading and updating it. Note also that even
if you hold the reference to a SLSB remote interface between the 2 calls
you will (most likely) get 2 different instances in the container. This is
why you can't save state data in a slsb.
Does this new example work correctly?
Thanks
David Jencks
On 2001.04.24 10:26:50 -0400 René Rolander Nygaard wrote:
> This is in fact exatly what we did.
> This was however a test, and we just could figure out what precisly went
> wrong.
>
> After your mail we did talk some more (here at the office) and now we got
> this simple question.
>
> If we from our JSP call a SLSB with a findByPrimary(something), and then
> afterwards FROM JSP calls setLastName(newLastName), and the EJB ref. is
> held
> in the SLSB - can we then not be 100% it is the same EJB we just found
> earlier.
>
> In this example, is the correct method:
>
> customerDataHolder currCustomer = SLSB.findByPrimary (loginName)
>
> customerDataHolder.setLastName (newLastName);
>
> SLSB.findAndSetCustomer (customerDataHolder);
> - and here the SLSB will make a new findByPrimary to make sure it is the
> correct customer.
> - and afterwards call the setCustomerData method.
>
> Please note that the bean layer is not included in this small example!
>
> Again - thanks for your responses!
>
> - René Rolander Nygaard
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of David
> Jencks
> > Sent: 24. april 2001 14:42
> > To: [EMAIL PROTECTED]
> > Subject: Re: [JBoss-user] Jboss-bug or misunderstanding ? (Loosing
> > reference to JBoss object)
> >
> >
> > Hi,
> > Since you don't include your code or many details it is hard for
> > me to know
> > exactly what is happening. You appear to be returning a ResultSet from
> a
> > SLSB. Assuming that this result set was obtained from a db connection,
> > this is a _VERY BAD IDEA_ even if it sometimes appears to work.
> > The result
> > sets I am familiar with depend on a connection to the database to fetch
> > more results when asked -- so they have to keep their association with
> the
> > connection, etc. However the design philosophy of a SLSB is that any
> work
> > is done within a single method invocation. Commit happens before you
> > return from the call. So where is the "more information" in the result
> set
> > supposed to come from (assuming snapshot or serializable transaction
> > isolation)?
> >
> > I suggest copying the information you are interested in into a
> standalone
> > object such as a collection of data objects or an xml string.
> >
> > If I have misunderstood your description of what you are doing I
> > apologize.
> >
> > David Jencks
> >
> >
> > On 2001.04.24 02:30:35 -0400 René Rolander Nygaard wrote:
> > > We are getting pretty desperate regarding this question, so I
> > have to ask
> > > again!
> > >
> > > Through our speed-testing we are seeing more strange behaviors.
> > > It seems as JBoss looses the reference to an object if you
> speed-clicks.
> > > This can only mean that the problems occurs because the same session
> is
> > > trying to access the same object more than once.
> > >
> > > If you from a jsp page force a reload before the last page-load was
> > > finished, it seems that the reference from the jsp page through to
> the
> > > JBoss
> > > stateless bean is lost!
> > >
> > > Can we expect that in one work-cycle we get a reference to at
> different
> > > JBoss stateless bean, and if this is the case - we cannot clean up
> after
> > > us
> > > self.
> > >
> > > The scenario again:
> > > A jsp page gets a reference to a stateless session bean
> > > The jsp page starts traverse a resultset
> > > <Here we reload the page!>
> > > The disconnect functions all fail because the objects == null!
> > > Sorry about this, but i cannot see this any other way than a
> > JBoss bug...
> > >
> > > Please, please, please help us out here!!!
> > >
> > > - René Rolander Nygaard
> > >
> > >
> >
> >
> > _______________________________________________
> > JBoss-user mailing list
> > [EMAIL PROTECTED]
> > http://lists.sourceforge.net/lists/listinfo/jboss-user
> >
>
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
