|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 3 of 6
By default, TopLink Essentials uses a cache that is shared by clients bound to a certain session. For example, if a client
retrieves an object from the database or stores an object in the database, a copy of the object is stored in the application
server's cache. Other clients can subsequently retrieve this object from the cache. The following problem now arises: Say
you add an entity, then remove it, and then add it again to the database. The last action causes an exception, which states
that the entity already exists. To resolve this issue, the toplink.cache.shared.default property must be set to false, as shown in Listing 2. This property lets you control if the cache can be shared by multiple clients or not. If you set
it to false, the cache is exclusively used by one client. This client can still refer to objects in a shared cache, but other clients
are not allowed to refer to objects in the exclusive cache.
As a final step, the classes used by TopLink Essentials must be added to the WebLogic server's classpath. A WebLogic server
operates with domains -- the basic administration units for WebLogic server instances. Each domain has its own configuration files, including a
file to configure which classes are loaded during startup. This file, which is in the domain-home/bin directory, is called setDomainEnv. To load the TopLink Essentials classes during startup, you must add this section to the setDomainEnv file:
@REM SET THE CLASSPATH
set TOPLINK=..\..\..\wlserver_10.3\ADF\lib\toplink-essentials.jar
set TOPLINK=%TOPLINK%;..\..\..\wlserver_10.3\ADF\lib\toplink-essentials-agent.jar
set CLASSPATH=%TOPLINK%;%PRE_CLASSPATH%...
The alterations I've just described are unnecessary if you use OC4J, because TopLink Essentials is OC4J's built-in persistence framework.
EJBs are components that encapsulate an application's business logic. Java EE's Java Naming and Directory Interface (JNDI) allows you to use an enterprise bean in a client, or enable the bean to use some resource configured on an application server. JNDI lets applications associate attributes with objects and search for those objects by using their attributes. For example, an application using JNDI can store and retrieve any type of Java object by its given JNDI name.
Consider an enterprise bean registered under the name ejb/JavaWorld:
@Remote
public interface JavaWorld {...}
@Stateless(name = "ejb/JavaWorld", mappedName = "ejb/JavaWorld")
public class JavaWorldBean implements JavaWorld {...}
This enterprise bean can subsequently be referred to by a client using a JNDI lookup. OC4J requires that the name associated
with the name attribute be used. WebLogic requires that the name associated with the mappedName attribute be used.
A container implements the environment for a component and presents this as a JNDI context. A component can approach this environment by using the JNDI interfaces: a component creates an InitialContext object to retrieve the context. This context can then be used to look up registered objects such as the ejb/JavaWorld enterprise bean. If you're using OC4J, you can retrieve the enterprise bean with: