I have a question about managing transaction in following
scenario:
If we want to use stateless session bean which uses entity
beans for persistence, how database transaction should be managed? Let us
assume persistence in entity bean is bean managed. Actual problem may arise
in case of concurrent access to entity bean instance by different clients
through session bean.
Regards,
Praful
-----Original Message-----
From: MARK HAPNER [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, March 08, 2000 9:10 AM
To: [EMAIL PROTECTED]
Subject: Re: Dependent classes in an ejb-jar
If you wish to include some classes an ejb jar depends on in
a different
library jar file the way to do that is to include a
reference to the
library jar in the ejb jar's class path (which is defined in
its jar
manifest); and put both the ejb jar and library jar in a
J2EE
application archive (a .ear file).
App servers are allowed to reject apps that are not
self-contained but
they are not required to do so.
See chapter 8 of the J2EE Spec for more details. The
inclusion of
libraries is covered under the category of 'bundled
extensions'.
J2EE does not define how an app can depend on app libraries
that may be
pre installed on the server.
Laird Nelson wrote:
>
> The EJB 1.0 (yes, 1.0; I'm working with Weblogic 4.5.1)
specification
> speaks thusly on page 118:
>
> The enterprise Bean provider is responsible for putting
the following
> classes
> and files in the ejb-jar file:
>
> * The enterprise Bean class with any classes that the
enterprise Bean
> depends
> on.
> [snip]
>
> My bean makes reference to some third-party non-EJB
classes (actually
> classes written in our company, but not managed by my
group). Let's say
> for the sake of argument that I can't bundle them with my
bean's jar
> file; instead it is simply a precondition for the bean's
deployment that
> those classes exist somewhere and are loadable by the EJB
server's
> classloader.
>
> Does the spec. have the intention (hi, Mark) of
prohibiting deployment
> if these required classes are not found by the container?
That is,
> should a strictly-compliant EJB 1.0 container ideally
reject deployment
> of my bean because its jar file does not physically
contain required
> classes (I hope not)?
>
> Alternatively, he mused, I don't suppose you can shove a
.jar file
> inside a .jar file and have its classes magically
recursively available
> to the second .jar file's classloader....
>
> Trying to be a good EJB citizen,
> Laird
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body
> of the message "signoff EJB-INTEREST". For general help,
send email to
> [EMAIL PROTECTED] and include in the body of the
message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and
include in the body
of the message "signoff EJB-INTEREST". For general help,
send email to
[EMAIL PROTECTED] and include in the body of the message
"help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
