Heiner KückerSpeicherklassen in Java |
||||||||||
|
Home Java-Seite Weiterentwicklung_Java NullPointer Algorithmische Symmetrie Finder_Feature Multiple_Interface Implementationen Proxy_Methoden Speicher_Klassen WebCam_Demo JSP WorkFlow PageFlow FlowControl Page Flow Engine Control_and_Command JSP_Spreadsheet Domain Parser Codegenerator_für hierarchische Datenstrukturen Expression_Engine Formula_Parser State Transition Engine AspectJ Java_Explorer DBF_Library Kalender_Applet SetGetGen BeanSetGet CheckPackage LineNumbers GradDms Excel-Export StringTokenizer JspDoc JspCheck JSP-Schulung Java Server Pages Struts AsciiTabellenLayouter StringSerial Silbentrennung JDBC_Schlüssel- Generierung bidirektional/ unidirektional gelinkte Liste Java_Sitemap Generator XmlBuilder RangeMap Alaska-XBase++-Seite Projekte Philosophien Techniken Konzepte Sudoku Kontakt / Impressum Links SiteMap Letzte Aktualisierung: 03.09.2002 |
SpeicherklassenJava besitzt drei Speicherklassen:
Hinzu kommt die Unterteilung der lokalen und dynamischen Variablen auf verschiedene Threads.
Problem 1Hier eine typische objektorientierte Architektur (nur nicht in UML gezeichnet):Ein Servlet ruft einen PDF-Generator aus einem isolierten Framework auf. Dieser PDF-Generator bekommt Code eingelagert um Text und Optionen für Seitenköpfe und -füße, Spaltenköpfe und -inhalte, Gruppierungen, Summierungen usw. zu liefern.
Üblicherweise werden hier komplizierte Verknotungstechniken eingesetzt.
Beispielweise könnten die eingelagerten Code-Teile mit Hilfe von
Inferface-Callback-Hooks, die man über
+------------------+ +------------------+ +------------------+
| | | | | |
| Servlet |-------- >| PDF-Generator |-------- >| Eingelagerter |
| | | | | Code zum |
| | | | | Liefern der |
| | | | | Daten |
| | | | | |
+------------------+ +------------------+ +------------------+
| |
| |
+----------------------- <- View <- -----------------------+
Diese Lösung ist unübersichtlich und für jeden Request müssen für die
Threadsicherheit neue Callback-Hook-Objekte erzeugt werden.
Problem 2
+--------------------------------------+
| Java-Server |
| |
| +--------+ Tabelle |
| | | mit |
Request + | +--------+ Session- |
Session-Ifo => | -------------> | | objekten |
| +--------+ |
| Zuordnung <-- | | |
| Session- +--------+ |
| objekt | | |
| | +--------+ |
| | |
| +-----> Aufruf Request mit |
| Sessionobjekt |
+--------------------------------------+
Der Java-Server nimmt die Requests entgegen und ermittelt aus dem Request des
Clients(Bowsers) die Session-Information, entnimmt aus einer Tabelle das
entsprechende Session-Objekt und ruft mit diesem die Request-Methode auf.
Neben Servlet-JSP sind die Twister-RDO´s (Brokat) ein weiteres Beispiel für diese Arbeitsweise.
Wünschenswert wären also neben den oben erwähnten noch die Speicherklassen
EJB verwendet mit stateless- und stateful-Session-Beans ein eigenes Modell. Demzufolge gilt mein Konzept nicht für EJB.
Meine IdeeWie so oft existiert die Lösung schon. Deshalb ist meine Idee als Synergie zu klassifizieren.Script-Sprachen und interpretierende Programmiersprachen wie BASIC besitzen einen RunTime-View. Dies gilt auch für die 4GL (Programmiersprachen der 4. Generation). ****************** funtion func1() a = "A" // Setzen Variable a b = func2() retu b ****************** function func2() return a * a // Variable a ist zur Laufzeit sichtbar ******************Die Variablen werden in eine Liste aus Name und Wert (Key und Value) gelegt und sind für jede gerufene Prozedur/Funktion sichtbar.
Denkbare SpracherweiterungenDer Runtime-Scope muß für jeden Thread getrennt exisiteren. Er könnte durch die Weitergabe von unsichtbaren Parametern realisiert werden:
public void method1(){
SessionObject so=new SessionObject()
Thread.setMagicMemory(so);
method2(anyParameters);
}//end method1
private void method2(anyParameters){//zusätzlicher unsichtbarer Parameter magicMemory
...
SessionObject so=Thread.getMagicMemory();
...
}//end method2
Die Methoden des fremden Frameworks geben bei jedem Aufruf transparent
(unwissentlich) die versteckten Parameter weiter, bis die eingelagerten
Codeteile darauf zugreifen und das Framework mit Daten versorgen.
//unsichtbare Weitergabe der Parameter für den Runtime-Scope
void strangeMethode(params(hidden params)){
...
//unsichtbare Weitergabe der Parameter für den Runtime-Scope
anotherStrangeMethod(params(hidden params));
...
}
Neben Speicherklassen für Request und Session könnten die unsichtbaren Parameter
noch feiner granulierte Speicherklassen realisieren.
SicherheitsregelnDer neue Speicher benötigt Sicherheitsvorkehrungen. So muß gesichert werden, daß sich nicht die Objekte verschiedener Applikationsteile mischen. dafür benötigt man Namen und Namensräume. Die Objekte/Klassen im Runtime-Scope-Speicherraum könnten ein Interface mit einer boolean-Methode zur Zugriffserlaubnis implementieren. Dieser Methode müßte eine Information über das zugreifende Objekt/Klasse bekommen.Ein einfacher Schutzmechanismus wäre die Beschränkung der Klassen-Sichtbarkeit auf die entsprechenden Packages. Bösartiger Code könnte sich der Introspection bedienen. Zum Schutz gegen Introspection ist auch ein Mechanismus über ein Acces-Schalter-Interface denkbar.
Realsierung mit vorhandenen SprachmittelnDie Thread-Klasse bekommt eine Erweiterung:public void Thread.setSession( HashMap sessionHashMap ) public HashMap Thread.getSession() public void Thread.setRequest( HashMap requestHashMap ) public HashMap Thread.getRequest()Die HashMaps arbeiten analog wie die Request- und Session-HashMaps bei Servlet-JSP. Der aktuelle Thread wird mit Thread.currentThread();ermittelt. Die Erweiterung kann leicht durch Vererbung realsiert werden. Alle Methoden die neue Threads erzeugen/starten müssen die HashMaps weitergeben. Hier ist es aber unbedingt notwendig, daß sich alle Code-Teile an die Regeln halten. Fremder Code ist evtl. problematisch. Eine weitere Lösungsmöglichkeit ist die Verwendung der vom Java-API mitgelieferten Klasse ThreadLocal.
VorteileDer Runtime-Scope erlaubt einfachere Applikationsarchitekturen.Weniger Callback-Klassen und weniger Code zum Verküpfen dieser Klassen könnte Speicher und Laufzeit sparen.
NachteileVariablen aus dem Runtime-Scope entziehen sich der Compiler-Prüfung, wodurch mehr Tests erforderlich werden.Eine Lösung wären fest compilierte Klassen die den neuen Speicherklassen zugeordnet werden.
public request class AppRequestClass{
BestellFormBean bestellFormBean;
...
}//end request class AppRequestClass
Dabei sinkt aber die Flexibiltät.
Eventuell wird die Kontrolle auf NullPointer notwendig.
Hier der Thread auf de.comp.lang.java zu diesem Thema |
|||||||||