Singleton-Session-Beans entwickeln
Erstellen Sie eine Bean-Implementierungsklasse für eine Singleton-Session-Bean, die in der in der Spezifikation EJB 3.1 eingeführt wurde. Der EJB-Container initialisiert nur eine einzige Instanz einer Singleton-Session-Bean, und diese Instanz wird von allen Clients gemeinsam genutzt. Da eine einzige Instanz von allen Clients gemeinsam genutzt wird, haben Singleton-Session-Beans eine spezielle Semantik für den Lebenszyklus und gemeinsamen Zugriff.
Vorbereitende Schritte
Informationen zu diesem Vorgang
public interface Configuration {
Object get(String name);
void set (String name, Object value);
}
@Singleton
public class ConfigurationBean implements Configuration {
private Map<String, Object> settings = new HashMap<String, Object>();
public Object get(String name) {
return settings.get(name);
}
public void set(String name, Object value) {
settings.put(name,value);
}
}
Wie bei anderen Enterprise-Bean-Typen können Sie Metadaten für Singleton-Session-Beans im Implementierungsdeskriptor deklarieren, anstatt Annotationen zu verwenden; z. B.:
<?xml version="1.0"?>
<ejb-jar
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/ejb-jar_3_1.xsd"
version="3.1"
>
<enterprise-beans>
<ejb-name>ConfigurationBean</ejb-name>
<business-local>com.ibm.example.Configuration</business-local>
<ejb-class>com.ibm.example.ConfigurationBean</ejb-class>
<session-type>Singleton</session-type>
</enterprise-beans>
</ejb-jar>
Vorgehensweise
- Codieren Sie die Initialisierungs- und Vernichtungsmethoden, und machen Sie sich damit vertraut, in welchem Bezug sie zu Ihren Optionen
für die Festlegung des Transaktionskontexts stehen. Während der Initialisierung geschieht Folgendes: Die Instanz wird erstellt, die Abhängigkeitsinjektion wird durchgeführt, und die Interceptor-Callbacks für den
PostConstruct-Lebenszyklus werden gestartet. Die Interceptor-Callbacks für den PreDestroy-Lebenszyklus
werden für eine Singleton-Session-Bean gestartet, wenn die übergeordnete Anwendung gestoppt wird.
Es kann hilfreich sein, Transaktionsaktivitäten während der Interceptor-Callbacks für die PostConstruct- und PreDestroy-Lebenszyklen auszuführen. Aus diesem Grund haben Interceptor-Callbacks für den Lebenszyklus von Singleton-Session-Beans einen klar strukturierten Transaktionskontext. Die folgenden Transaktionskontextwerte gleichen @Timeout-Methoden: Es können nur REQUIRED (Standardwert), REQUIRES_NEW und NOT_SUPPORTED verwendet werden, und REQUIRED wird in REQUIRES_NEW übersetzt.
Transaktionsattribute werden nur erkannt, wenn sie in den Interceptormethoden für den Lebenszyklus in der Bean-Klasse angegeben sind. Für alle Lebenszyklus-Interceptor wird derselbe Transaktionskontext verwendet. Das folgende Beispiel veranschaulicht eine Singleton-Session-Bean mit Transaktionsattributen für die Callbacks "PostConstruct" und "PreDestroy" für Lebenszyklusinterceptor.
@Singleton public class ConfigurationBean implements Configuration { @PostConstruct @TransactionAttribute(REQUIRED) // Standardwert, zur Veranschaulichung angegeben public void initialize() { // ... } @PreDestroy @TransactionAttribute(NOT_SUPPORTED) public void destroy() { // ... } // ... }
Anstatt eine Annotation zu verwenden, können Sie dieselben Metadaten über den XML-Implementierungsdeskriptor angeben. Wenn Sie Transaktionsattribute im XML-Implementierungsdeskriptor angeben, werden alle aus der Annotation "@TransactionAttribute" abgerufenen Metadaten ignoriert. Im folgenden Beispiel wird der XML-Implementierungsdeskriptor verwendet, um dieselben Metadaten wie im vorherigen Beispiel anzugeben.
<assembly-descriptor> <container-transaction> <method> <ejb-name>ConfigurationBean</ejb-name> <method-name>initialize</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction> <container-transaction> <method> <ejb-name>ConfigurationBean</ejb-name> <method-name>destroy</method-name> </method> <trans-attribute>NotSupported</trans-attribute> </container-transaction> </assembly-descriptor>
- Sofern nicht anders angegeben, wird die Instanz der Singleton-Session-Bean
gewöhnlich initialisiert, wenn die Bean zum ersten Mal über eine der zugehörigen Clientsichten
verwendet wird. Dies ist dieselbe Vorgehensweise wie bei anderen Session-Beans. Verwenden Sie die Annotation "@Startup" oder den entsprechenden
XML-Implementierungsdeskriptor, um eine Bean als Startup-Bean zu markieren. Die Markierung einer
Singleton-Bean als Startup-Bean bedeutet, dass der EJB-Container die Methode "PostConstruct" ausführen muss,
bevor er externe Clientanforderungen unterstützt, die an die auszuführende Anwendung gesendet werden.
Eine Methode "PostConstruct" in einer Singleton-Bean kann einen EJB-Zeitgeber erstellen,
einer JMS-Warteschlange oder einem JMS-Topic eine Nachricht hinzufügen, eine
asynchrone EJB-Methode aufrufen oder andere asynchrone Mechanismen zum Aufruf einer EJB starten.
Zur Vermeidung von Deadlocksituationen darf die Methode "PostConstruct" nicht auf die Ausführung
eines EJB-Zeitgebers, auf den Aufruf einer MDB-Methode oder auf die Beendigung einer
asynchronen EJB-Methode warten.
Anwendungsentwickler können in die Methode "PostConstruct" dieser Startup-Singleton-Instanzen Geschäftslogik für Tasks einfügen, die ausgeführt werden müssen, bevor Clientarbeiten vom Container gestartet werden, wie z. B. das Vorabladen von Caches oder das Starten asynchroner Arbeiten in der Anwendung.
Das folgende Beispiel veranschaulicht eine Singleton-Session-Bean mit Initialisierung beim Start:
@Singleton @Startup public class ConfigurationBean implements Configuration { @PostConstruct public void initialize() { // 1. Datenbanktabelle erstellen, sofern diese nicht vorhanden ist. // 2. Einstellungen aus der Datenbanktabelle initialisieren. // 3. Cache laden. // 4. Asynchrone Arbeitsvorgänge einleiten (z. B. Arbeiten für eine Messaging-Warteschlange oder für // aufrufe asynchroner Session-Bean-Methoden. } // ... }
Anstatt eine Annotation zu verwenden, können Sie dieselben Metadaten über den XML-Implementierungsdeskriptor angeben. Geben Sie true an, um diese Singleton-Bean als Startup-Singleton zu markieren. Geben Sie false an, und die Annotation "@Startup" wird überschrieben, wenn sie in der Klassendatei enthalten ist.
<session> <ejb-name>ConfigurationBean</ejb-name> <init-on-startup>true</init-on-startup> </session>
- Stellen Sie fest, ob die Initialisierungsmethode der Singleton-Session-Bean
implizit von einer anderen Singleton-Session-Bean abhängig ist.
Wenn eine implizite Abhängigkeit vorhanden ist, verwenden Sie die Abhängigkeitsmetadaten, um die Abhängigkeit explizit zu machen. Der Container stellt sicher, dass abhängige Beans erst nach den Singleton-Beans, von denen sie abhängig sind, initialisiert und vor dem Löschen der Singleton-Beans, von denen sie abhängig sind, gelöscht werden. Im Folgenden Beispiel sehen Sie eine Singleton-Session-Bean mit Abhängigkeitsmetadaten:
@Singleton public class DatabaseBean { @PostConstruct public void initialize() { // Datenbanktabellen erstellen } } @Singleton @DependsOn({"DatabaseBean"}) public class ConfigurationBean implements Configuration { @PostConstruct public void initialize() { // Einstellungen aus einer Datenbanktabelle initialisieren } // ... }
Außerdem können Sie mithilfe der ejb-link-Syntax module.jar#bean modulübergreifende Abhängigkeiten erstellen. Schleifenabhängigkeiten werden nicht unterstützt und bewirken, dass die Anwendung fehlschlägt.
Anstatt eine Annotation zu verwenden, können Sie dieselben Metadaten über den XML-Implementierungsdeskriptor angeben. Wenn Sie Abhängigkeitsmetadaten im XML-Implementierungsdeskriptor angeben, werden alle Metadaten aus der Annotation "@DependsOn" ignoriert.
<session> <ejb-name>ConfigurationBean</ejb-name> <depends-on> <ejb-name>DatabaseBean</ejb-name> </depends-on> </session>
- Legen Sie fest, ob containergesteuerte oder Bean-gesteuerte gemeinsame Zugriffe verwendet werden sollen. Die Annotationen "@Lock" und "@AccessTimeout" sind nicht anwendbar, wenn Bean-gesteuerte gemeinsame Zugriffe verwendet werden.
Sie können die Annotation "@ConcurrencyManagement" nur in einer Singleton-Session-Bean-Klasse implementieren. Sie kann weder in der Klasse verwendet werden, die erweitert wird, noch in Klassen, die in der Klassenvererbungsbaumstruktur über dieser Klasse stehen.
Das folgende Codebeispiel veranschaulicht eine Singleton-Bean mit Bean-gesteuerten gemeinsam Zugriffen:@Singleton @ConcurrencyManagement(BEAN) public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); synchronized public Object get(String name) { return settings.get(name); } synchronized public void set(String name, Object value) { settings.put(name, value); } }
Anstatt eine Annotation zu verwenden, können Sie dieselben Metadaten über den XML-Implementierungsdeskriptor angeben. Wenn die Metadaten im XML-Implementierungsdeskriptor und über die Annotation "@ConcurrencyManagement" angegeben werden, muss der Wert übereinstimmen, oder es tritt ein Fehler in der Anwendung auf. Im folgenden Beispiel wird der XML-Implementierungsdeskriptor verwendet, um dieselben Metadaten wie im vorherigen Beispiel anzugeben.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrency-management-type>Bean</concurrency-management-type> </session>
Der Container setzt nicht für jede aufgerufene Methode Sperren. Vielmehr ist die eigentliche Bean für die erforderlichen Sperren verantwortlich. In dem Beispiel hat sich der Bean-Provider für die Implementierung der Methoden über das Schlüsselwort "synchronized" entschieden. Dies wird für Singleton-Session-Beans mit beangesteuerten gemeinsamen Zugriffen unterstützt, aber nicht für andere EJB-Komponententypen. Es ist nicht erforderlich, dass der Bean-Provider das Schlüsselwort für die "synchronized" für die Unterstützung gemeinsamer Zugriffe verwendet. Der Bean-Provider kann beispielsweise auch die Klasse "java.util.concurrent.locks.ReentrantReadWriteLock" in JDK 5 und höher verwenden.
Die laut der Spezifikation EJB 3.1 erforderliche Sperrsemantik für containergesteuerte gemeinsame Zugriff entspricht dem Verhalten der Klasse "java.util.concurrent.locks.ReentrantReadWriteLock".
- Wenn Sie containergesteuerte gemeinsame Zugriffe verwenden, verwenden Sie die Annotation "@Lock" für die Verwaltung gemeinsamer Methodenzugriffe. Das folgende Codebeispiel veranschaulicht eine Singleton-Instanz mit containergesteuerten gemeinsamen Zugriffen:
@Singleton public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); @Lock(READ) public Object get(String name) { return settings.get(name); } public void set(String name, Object value) { settings.put(name, value); } }
Anstatt eine Annotation zu verwenden, können Sie dieselben Metadaten über den XML-Implementierungsdeskriptor angeben. Wenn die Metadaten im XML-Implementierungsdeskriptor und in der Annotation "@Lock" angegeben sind, werden die aus der Annotation "@Lock" abgerufenen Metadaten ignoriert. Im folgenden Beispiel wird der XML-Implementierungsdeskriptor verwendet, um dieselben Metadaten wie im vorherigen Beispiel anzugeben.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>get</method-name> </method> <lock>Read</lock> </concurrent-method> </session>
Das Beispiel veranschaulicht auch die Annotation einer Methode mit "@Lock(READ)", um anzuzeigen, dass der Container eine Leersperre erhalten muss, wenn diese Methode gestartet wird. Wenn eine Methode mit @Lock annotiert ist, überschreibt sie die Annotation "@Lock", die auf Klassenebene angegeben ist. Falls es keine Annotation "@Lock" auf Klassenebene gibt, wird standardmäßig eine Schreibsperre angefordert. In diesem Beispiel überschreibt @Lock(READ) in der Methode die Standardschreibsperre auf Klassenebene. Wenn eine Methode auf Methodenebene nicht annotiert ist und keine Annotation auf Klassenebene vorhanden ist, wird die standardmäßig eine Schreibsperre vom Container verwendet.
Da die meisten Methoden eine Lesesperre erfordern, verwenden Sie @Lock(READ) auf Klassenebene, um anzuzeigen, dass der Container für alle Geschäftsmethoden in dieser Klasse eine Lesesperre anfordern muss. Für Methoden, die eine Schreibsperre erfordern, annotieren Sie diese Methoden mit @Lock(WRITE), um anzuzeigen, dass diese Annotation die Lesesperre überschreiben soll, die auf Klassenebene angegeben ist.
Das folgende Beispiel veranschaulicht diese Technik:
@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { private Map<String, Object> settings = new HashMap<String, Object>(); public Object get(String name) { return settings.get(name); } @Lock(WRITE) public void set(String name, Object value) { settings.put(name, value); } }
Die Annotation "@Lock" gilt nur für Methoden, die in derselben Klasse wie die Annotation "@Lock" deklariert sind. Die Metadaten für @Lock in einer bestimmten Klasse werden nie von einer Klasse übernommen, die in der Klassenvererbungsbaumstruktur über dieser Klasse stehen. Anstatt eine Annotation auf Klassenebene zu verwenden, können dieselben Metadaten im XML-Implementierungsdeskriptor mit dem Sondermethodennamen * angegeben, der allen Methoden entspricht.
- Wenn Sie containergesteuerte gemeinsame Zugriffe verwenden, verwenden Sie die Notation "@AccessTimeout",
um zu beschränken, wie lange eine Methode auf die Erteilung einer Sperre wartet. Das folgende Codebeispiel veranschaulicht die Zeitlimits für gemeinsame Zugriffe:
@Singleton public class ConfigurationBean implements Configuration { @Lock(READ) @AccessTimeout(1000) public Object get(String name) { // Datenbank abfragen } public void set(String name, Object value) { // Datenbank aktualisieren } }
Wenn keine Annotation angegeben ist, wartet die Methode standardmäßig so lange, bis eine Sperre erteilt wird. Es gibt kein Zeitlimit für das Warten auf eine Sperrre. Da keine Festlegung auf Klassenebene codiert ist, gibt es für alle Methoden der Klasse kein Wartezeitlimit für die Erteilung einer Sperre. Wenn die Annotation "@AccessTimeout" verwendet wird und der Container die Sperre nicht innerhalb des angegebenen Zeitlimits erteilen kann, wird ein Ausnahme des Typs "javax.ejb.ConcurrentAccessTimeoutException" an den Client ausgegeben. Die Annotation "@AccessTimeout" gilt nur für Methoden, die in derselben Klasse wie die Annotation "@AccessTimeout" deklariert sind. Die Metadaten für die Annotation "@AccessTimeout" in einer bestimmten Klasse werden nie von einer Klasse übernommen, die in der Klassenvererbungsbaumstruktur über dieser Klasse stehen.
Wenn die Metadaten im XML-Implementierungsdeskriptor und in der Annotation "@Lock" angegeben sind, werden die aus der Annotation "@Lock" abgerufenen Metadaten ignoriert. Im folgenden Beispiel wird der XML-Implementierungsdeskriptor verwendet, um dieselben Metadaten wie im vorherigen Beispiel anzugeben.
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>get</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>1000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
- Sie müssen wissen, dass die XML-Codierung von concurrent-methodType
den drei Stilen entspricht, die in der EJB-Spezifikation für die Erstellung der XML-Elemente für
Containertransaktionsmethoden beschrieben sind.
Denken Sie daran, dass die Elemente "lock" und "access-timeout" optional sind. Die drei Stile sind im Folgenden beschrieben:
Stil 1 verwendet den Sondermethodennamen *, um den Sperrtypen und/oder den Wert für das Zugriffszeitlimit auf alle Geschäftsmethoden der angegebenen Bean anzuwenden.
<!-- Beispiel: Stil 1 --> <concurrent-method> <method> <method-name>*</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
Stil 2 wird verwendet, um auf eine Geschäftsmethode mit einem bestimmten Namen zu verweisen und dieser den angegebenen Sperrtyp und/oder den angegebenen Zugriffszeitlimitwert zuzuordnen. Wenn der Methodenname überladen ist, was bedeutet, das mehrere Methoden denselben Namen, aber unterschiedliche Methodensignaturen haben, haben alle Methoden mit diesem Namen den angegebenen Sperrtyp und/oder den angegebenen Zugriffszeitlimitwert. Stil 2 hat Vorrang vor Stil 1.
<!-- Beispiel: Stil 2 --> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
Stil 3 wird verwendet, um auf eine bestimmte Methode zu verweisen, die dem angegebenen Methodennamen entspricht und eine Methodensignatur besitzt, die den aufgelisteten Methodenparamtern entspricht. Stil 3 hat Vorrang vor den Stilen 1 und 2.
<!-- Beispiel: Stil 3 --> <concurrent-method> <method> <method-name>businessMethod</method-name> <method-params> <method-param>long</method-param> <method-param>int</method-param> </method-params> </method> <lock>Read</lock> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method>
Wenn XML-Stil 1 verwendet wird, um einen Sperrtyp zu definieren, werden alle Annotationen "@Lock" in der Bean ignoriert. Dasselbe gilt für das Zugriffszeitlimit. Wenn XML-Stil 1 verwendet wird, um eine Zugriffszeitlimitwert zu definieren, werden alle Annotationen "@AccessTimeout" in der Bean ignoriert.
- Sie müssen unbedingt verstehen, dass die Annotationen "@Lock" und "@AccessTimeout"
wie auch die entsprechenden XML-Implementierungsdeskriptorcodes unabhängig voneinander behandelt werden.
Die Implementierung dieses Konzepts hat mehrere Vorteile. Diese Trennung von Sperrtyp und Zugriffszeitlimit hilft Ihnen zu verhindern, dass Anwendungscode für Funktionseinheiten beeinträchtigt wird, weil Sie den Sperrtyp nicht wissen müssen. Sie können den Sperrtypwert bedenkenlos übernehmen und nur den Zugriffszeitlimitwert an Ihre Umgebungsanforderungen anpassen und damit mögliche Deadlock-Situationen oder andere Probleme mit gemeinsamen Zugriffen vermeiden.
Angenommen, Sie führen vom Anbieter bereitgestellte EJB-Anwendung aus, und aufgrund einer verlangsamten Systemleistung tritt eine Zeitlimitüberschreitung auf. Sie möchten die Sperrlogik nicht ändern, weil Sie befürchten, Deadlocksituationen zu verursachen, möchten aber das Zeitlimit ändern. In diesem Fall können Sie den Implementierungsdeskriptor bearbeiten und den Zugriffszeitlimitwert angeben, den Sie für die Methoden benötigen, die Sie ändern möchten.Das folgende Beispiel zeigt, wie Sie lediglich eine Annotation "@Lock(READ)" auf Methodenebene in der Beanimplementierung angeben und Stil 2 für die Erstellung der XML verwenden können, um das Element "access-timeout" auf 2.000 Millisekunden zu setzen, ohne das optionale Element "lock" zu definieren. Das Ergebnis ist eine Methode mit einer Lesesperre, die ein Zugriffszeitlimit von 2.000 Millisekunden hat.
@Singleton public class ConfigurationBean implements Configuration { @Lock(READ) public Object businessMethod(long value) { // ... } // ... }
Sie können auch eine Sperrannotation auf Klassenebene verwenden und dann den gewünschten Zugriffszeitlimitwert in der XML in Stil 3 und/oder Stil 3 angeben, wie im folgenden Beispiel gezeigt wird.<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { public Object businessMethod(long value) { // ... } public Object businessMethod(long value, int i, Object value) { // ... } public Object businessMethod(long value, int i) { // ... } }
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> <concurrent-method> <method> <method-name>businessMethod</method-name> <method-params> <method-param>long</method-param> <method-param>int</method-param> </method-params> </method> <access-timeout> <timeout>8000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
Das er vorherige Codebeispiel bewirkt, dass alle Methoden mit dem Namen "businessMethod" den Sperrtyp "read" (Lesen) und ein Zugriffszeitlimit von 2.000 Millisekunden haben. Die Ausnahme ist die eine Instanz der Methode "businessMethod", die eine Methodensignatur hat, deren erster Parameter den Typ "long" und deren zweiter Parameter den Typ "int" hat. Diese Instanz der Methode "businessMethod" hat den Sperrtyp "read" (Lesen), aber ein Zugriffszeitlimit von 8.000 Millisekunden.
Dasselbe Prinzip gilt, wenn der XML-Stil 1 verwendet wird, um nur einen Sperrtyp, aber keinen Zugriffszeitlimitwert zu definieren. Sie können bestimmten Methoden einen Zugriffszeitlimitwert mit Stil 2 und/oder Stil 3 hinzufügen, um ein Ergebnis mit einem bestimmten Sperrtyp und einem bestimmten Zugriffszeitlimitwert zu erhalten. Dies wird im folgenden Beispiel veranschaulicht:<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>*</method-name> </method> <lock>Read</lock> </concurrent-method> <concurrent-method> <method> <method-name>businessMethod</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
Das vorherige Codebeispiel bewirkt, dass alle Geschäftsmethoden den Sperrtyp "read" haben und dass die Methode mit dem Namen "businessMethod" den Sperrtyp "read" und ein Zugriffszeitlimit von 2.000 Millisekunden hat.
Sie können auch eine Annotation "@Lock" auf Klassenebene definieren, um den Sperrtyp für alle Methoden festzulegen, und Stil 1 für die XML-Erstellung verwenden, um nur den Zugriffszeitlimitwert für alle Methoden festzulegen. Sehen Sie sich das folgende Beispiel an:@Singleton @Lock(READ) public class ConfigurationBean implements Configuration { public Object businessMethod(long value) { // ... } // ... }
<session> <ejb-name>ConfigurationBean</ejb-name> <concurrent-method> <method> <method-name>*</method-name> </method> <access-timeout> <timeout>2000</timeout> <unit>Milliseconds</unit> </access-timeout> </concurrent-method> </session>
Das vorherige Beispiel bewirkt, dass alle Geschäftsmethoden der Bean "ConfigurationBean" den Sperrtyp "read" und einen Zugriffszeitlimitwert von 2.000 Millisekunden haben.
- Stellen Sie sicher, dass Sie die Vererbungsregeln für die verwendeten Annotationen verstehen.
- Vermeiden Sie Verhalten mit simultan verwendbaren Sperreen, das eintreten kann, wenn eine Methode
mit dem Sperrtyp "read" (Lesen) eine Methode mit dem Sperrtyp "write" (Schreiben) in derselben Singleton-Session-bean aufruft.
Angenommen, die Geschäftsmethode einer Singleton-Session-Bean bewirkt direkt oder indirekt, dass eine andere Geschäftsmethode der Singleton-Session-Bean gestartet wird. Wenn die erste Methode eine Methode mit dem Sperrtyp "write" (Schreiben) ist, kann diese Methode jede andere Geschäftsmethode der Singleton-Session-Bean aufrufen, ohne spezielle Vorgaben zu berücksichtigen. Wenn Sie jedoch eine Methode mit dem Sperrtyp "read" (Lesen) implementieren, die eine andere Geschäftsmethode derselben Singleton-Session-Bean-Klasse aufrufen soll, die eine Methode mit dem Sperrtyp "write" (Schreiben) ist, tritt eine Ausnahme des Typs javax.ejb.IllegalLoopbackException ein.
Unterartikel
Sperrrichtlinie für Singleton-Session-Beans ändern
Verwenden Sie diese Task, um die standardmäßig verwendete Sperrrichtlinie vom Typ "non-fair" (Non-Fair Policy) für alle Schreibsperren im Server, die Singleton-Session-Beans betreffen, außer Kraft zu setzen. Diese Task ist für Benutzer von WebSphere Application Server vorgesehen, die keine Anforderungen von Methodenaufrufen für Singleton-Session-Beans sperren und eine Richtlinie vom Typ "non-fair" verwenden möchten.Sperrrichtlinie für Singleton-Session-Beans ändern
Verwenden Sie diese Task, um die standardmäßig verwendete Sperrrichtlinie vom Typ "non-fair" (Non-Fair Policy) für alle Schreibsperren im Server, die Singleton-Session-Beans betreffen, außer Kraft zu setzen. Diese Task ist für Benutzer von WebSphere Application Server vorgesehen, die keine Anforderungen von Methodenaufrufen für Singleton-Session-Beans sperren und eine Richtlinie vom Typ "non-fair" verwenden möchten.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tejb_ssb
Dateiname:tejb_ssb.html