16. What is EJB QL?
EJB QL is a Query Language provided for navigation across a network of
enterprise beans and dependent objects defined by means of container managed
persistence. EJB QL is introduced in the EJB 2.0 specification. The EJB QL
query language defines finder methods for entity beans with container managed
persistence and is portable across containers and persistence managers. EJB QL
is used for queries of two types of finder methods: Finder methods that are
defined in the home interface of an entity bean and which return entity
objects. Select methods, which are not exposed to the client, but which are
used by the Bean Provider to select persistent values that are maintained by
the Persistence Manager or to select entity objects that are related to the
entity bean on which the query is defined.
17. Brief description about local interfaces?
EEJB was originally designed around remote invocation using the Java Remote
Method Invocation (RMI) mechanism, and later extended to support to standard
CORBA transport for these calls using RMI/IIOP. This design allowed for
maximum flexibility in developing applications without consideration for the
deployment scenario, and was a strong feature in support of a goal of
component reuse in J2EE. Many developers are using EJBs locally, that is, some
or all of their EJB calls are between beans in a single container. With this
feedback in mind, the EJB 2.0 expert group has created a local interface
mechanism. The local interface may be defined for a bean during development,
to allow streamlined calls to the bean if a caller is in the same container.
This does not involve the overhead involved with RMI like marshalling etc.
This facility will thus improve the performance of applications in which
co-location is planned. Local interfaces also provide the foundation for
container-managed relationships among entity beans with container-managed
persistence.
18. What are the special design cares that must be taken when you work with
local interfaces?
It is important to understand that the calling semantics of local interfaces
are different from those of remote interfaces. For example, remote interfaces
pass parameters using call-by-value semantics, while local interfaces use
call-by-reference. This means that in order to use local interfaces safely,
application developers need to carefully consider potential deployment
scenarios up front, then decide which interfaces can be local and which
remote, and finally, develop the application code with these choices in mind.
While EJB 2.0 local interfaces are extremely useful in some situations, the
long-term costs of these choices, especially when changing requirements and
component reuse are taken into account, need to be factored into the design
decision.
19. What happens if remove( ) is never invoked on a session bean?
In case of a stateless session bean it may not matter if we call or not as in
both cases nothing is done. The number of beans in cache is managed by the
container. In case of Stateful session bean, the bean may be kept in cache
till either the session times out, in which case the bean is removed or when
there is a requirement for memory in which case the data is cached and the
bean is sent to free pool.
20. What is the difference between Message Driven Beans and Stateless
Session beans?
In several ways, the dynamic creation and allocation of message-driven bean
instances mimics the behavior of stateless session EJB instances, which exist
only for the duration of a particular method call. However, message-driven
beans are different from stateless session EJBs (and other types of EJBs) in
several significant ways: Message-driven beans process multiple JMS messages
asynchronously, rather than processing a serialized sequence of method calls.
Message-driven beans have no home or remote interface, and therefore cannot be
directly accessed by internal or external clients. Clients interact with
message-driven beans only indirectly, by sending a message to a JMS Queue or
Topic. Only the container directly interacts with a message-driven bean by
creating bean instances and passing JMS messages to those instances as
necessary. The Container maintains the entire lifecycle of a message-driven
bean; instances cannot be created or removed as a result of client requests or
other API calls.
22. How can I call one EJB from inside of another EJB?
EJBs can be clients of other EJBs. It just works. Use JNDI to locate the Home
Interface of the other bean, then acquire an instance reference, and so forth.
23. What is an EJB Context?
EJBContext is an interface that is implemented by the container, and it is
also a part of the bean-container contract. Entity beans use a subclass of
EJBContext called EntityContext. Session beans use a subclass called
SessionContext. These EJBContext objects provide the bean class with
information about its container, the client using the bean and the bean
itself. They also provide other functions. See the API docs and the spec for
more details.
24. Is it possible for an EJB client to marshal an object of class
java.lang.Class to an EJB?
Technically yes, spec. compliant NO! - The enterprise bean must not attempt to
query a class to obtain information about the declared members that are not
otherwise accessible to the enterprise bean because of the security rules of
the Java language.
25. Is it legal to have static initializer blocks in EJB?
Although technically it is legal, static initializer blocks are used to
execute some piece of code before executing any constructor or method while
instantiating a class. Static initializer blocks are also typically used to
initialize static fields - which may be illegal in EJB if they are read/write
- In EJB this can be achieved by including the code in either the ejbCreate(),
setSessionContext() or setEntityContext() methods.
26. Is it possible to stop the execution of a method before completion in a
SessionBean?
Stopping the execution of a method inside a Session Bean is not possible
without writing code inside the Session Bean. This is because you are not
allowed to access Threads inside an EJB.
27. What is the default transaction attribute for an EJB?
There is no default transaction attribute for an EJB. Section 11.5 of EJB v1.1
spec says that the deployer must specify a value for the transaction attribute
for those methods having container managed transaction. In Weblogic, the
default transaction attribute for EJB is SUPPORTS.
28. What is the difference between session and entity beans? When should I
use one or the other?
An entity bean represents persistent global data from the database; a session
bean represents transient user-specific data that will die when the user
disconnects (ends his session). Generally, the session beans implement
business methods (e.g. Bank.transferFunds) that call entity beans (e.g.
Account.deposit, Account.withdraw)
29. Is there any default cache management system with Entity beans?
In other words whether a cache of the data in database will be maintained in
EJB? - Caching data from a database inside the Application Server are what
Entity EJBs are used for. The ejbLoad() and ejbStore() methods are used to
synchronize the Entity Bean state with the persistent storage(database).
Transactions also play an important role in this scenario. If data is removed
from the database, via an external application - your Entity Bean can still be
alive the EJB container. When the transaction commits, ejbStore() is called
and the row will not be found, and the transaction rolled back.
30. Why is ejbFindByPrimaryKey mandatory?
An Entity Bean represents persistent data that is stored outside of the EJB
Container/Server. The ejbFindByPrimaryKey is a method used to locate and load
an Entity Bean into the container, similar to a SELECT statement in SQL. By
making this method mandatory, the client programmer can be assured that if
they have the primary key of the Entity Bean, then they can retrieve the bean
without having to create a new bean each time - which would mean creating
duplications of persistent data and break the integrity of EJB.