Hallo Pete,
> Good software always shows symmetry. However, the an entity bean's remove method can
> only throw RemoveException (or derived exceptions of course). There is no way i can
> extend the remove method to throw a custom application exception (like my own
> "ValidationException").
The
I completely agree with you - and SUN should do
something to revise their spec for this. Whats the
pupose of an ejbRemove if I still have to have
finalize blocks or have to catch RuntimeExceptions in
an EJB framework?
Anamitra
--- Hardy Henneberg <[EMAIL PROTECTED]> wrote:
> Hi Anamitra,
> Thanks
Hi Anamitra,
Thanks for bring up this problem, which has bothered me too.
Not only with SLSB's but with all type of enterprise beans, because a system
exception from an enterprise bean will always make the container discard the
bean without calling ejbRemove or another callback method.
My "best" s
yeah - maybe I should consider that - or maybe create
my own pool of sessions.
thanks
Anamitra
--- Benjamin BONNET
<[EMAIL PROTECTED]> wrote:
> What about using the finalize() method ?
> Benjamin
>
> Anamitra Bhattacharyya a écrit :
>
> > Hi Victor
> > thats a good point - So it seems that only th
Title: Re: ejbRemove question for StatelessSession bean
What about using the finalize() method ?
Benjamin
Anamitra Bhattacharyya a écrit :
> Hi Victor
> thats a good point - So it seems that only those
> resourses obtained from the resource factories
> declared in the b
Hi Victor
thats a good point - So it seems that only those
resourses obtained from the resource factories
declared in the bean env will be released by the
container. But unfortunately mine is not - so I guess
I will have to think of another solution.
thanks
Anamitra
--- Victor Langelo <[EMAIL PROT
Of course, Chapter 18 contradicts this by saying that the container must
not call any call back methods when discarding an instance due to an
system exception. However, section 18.3.7 states that all resources
obtained from resource factories declared in the bean environment must
be released. Mayb
Anamitra,
According to the 2.0 spec, the only state transition from the method
ready pool to does not exist state requires that the ejbRemove method be
called. So your ejb container does not comply with the spec. Section
7.8.3 explicitly states that exceptions result in the transition to the
does
CTED]] On Behalf Of Anamitra Bhattacharyya
> Sent: Monday, August 12, 2002 2:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: ejbRemove question for StatelessSession bean
>
>
> that is not an option - I gues my question can be
> generalised like this - if a stateless session bean
>
that is not an option - I gues my question can be
generalised like this - if a stateless session bean
takes resource like a db connection or jms
session/producers - then how does it make sure it can
close it?
Taking the resource locally and using it and then
closing it in a finally block is not go
Hi,
I think you'd be well served by a good book to get you started. Have a look at
somewhere like www.theserverside.com that offers
online reading (free membership required).
the method you are calling is in the EntityBean interface:
http://java.sun.com/products/ejb/javadoc-2_0-fr/javax/ejb/En
Title: RE: ejbRemove immediate?
Assaf,
According to Specs v1.1 actually the data shud be removed after the remove() is called. So may be BEA is futuristic in its approach. :-)
Mahendra
-Original Message-
From: Assaf Arkin [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 15, 2000
Michael Pikounis wrote:
> Anyone knows of a way
> to force weblogic (4.5.1) to call ejbRemove immediately (when I call
> bean.remove()) rathen than wait until the end of the transaction?
Examine their deployment descriptors for an attribute called something
like delayUpdatesUntilEndOfTransaction.
Hi Michael,
why dont u do tx.commit() and then call the find method --- that should
solve the problem. And in 5.1 WLS I tried to access the bean twice in the
same tx and it gave an error -- this is because while in tx the entity bean
is locked and is not free until the tx ends.
U can also try sett
Michael Pikounis wrote:
> I have the following problem when using the remove() method of a bean
> managed entity bean:
>
> step 1: call bean.remove() to remove the bean
> step 2: call Enumeration i = home.findBySomeCriterion( criteria )
>
> my enumeration contains the bean I removed, becau
Once you removed an entity bean it might still exist in the database,
but the EJB container should refuse to give it back to you, and if you
insist on using the reference you already got, through an exception.
Just file a bug report with BEA.
arkin
Michael Pikounis wrote:
>
> Hello all!
>
> I h
To: [EMAIL PROTECTED]
> Subject: Re: ejbRemove without ejbLoad?
>
> The answer to this question is the same as to your previous
> question on ejbRemove with BMP. In both cases, the container
> must ensure that the instance variables are up-to-date before
> dispatching the ejbRemo
The answer to this question is the same as to your previous
question on ejbRemove with BMP. In both cases, the container
must ensure that the instance variables are up-to-date before
dispatching the ejbRemove method.
This means that unless the
container is certain that the instance variables are
18 matches
Mail list logo
