EJB 2.0

[brauner1990]

Guten Morgen Com!

Ich muss aktuell ein Programm warten, welches von einem Studenten geschrieben wurde als Abschlussarbeit. Daher ist hier vieles drin, z.B. Lomboz, welches es schwierig macht mir es zu verstehen.

Ich bekomme hier mehrere Exceptions

1. Ex

javax.ejb.EJBException: Application Error: tried to enter Stateful bean with different tx context,
     contextTx: TransactionImple < ac, BasicAction: -3f579c36:464:4ffbc814:cf status: 
     ActionStatus.RUNNING >, methodTx: TransactionImple < ac, BasicAction: 
     -3f579c36:464:4ffbc814:d1 status: ActionStatus.RUNNING >

2. Ex

org.jboss.resource.adapter.jms.inflow.JmsActivationSpec@19a681
     (ra=org.jboss.resource.adapter.jms.JmsResourceAdapter@1cd4840 destination=queue/QueueJobStarterBean destinationType=javax.jms.Queue tx=true 
     durable=false reconnect=10 provider=DefaultJMSProvider user=null maxMessages=1 minSession=1 maxSession=15 keepAlive=30000 
     useDLQ=true DLQHandler=org.jboss.resource.adapter.jms.inflow.dlq.GenericDLQHandler DLQJndiName=queue/DLQ DLQUser=null DLQMaxResent=10)

Diese Excpetions sind vorraussichtlich ohne Zusammenhang, aber hat jmd ne Idee wie ich die 2. in den Griff bekomme und woher die erste stammen könnte?

Ich bedanke mich schonmal bei euch

mfg

 

[brauner1990]

2. Ex ist behoben. Scheint eine Inkompabilität zwischen EJB2.0 und JBoss5.1 zu sein. Auf einem JBoss4.0 funktioniert es

 

[brauner1990]

ERROR [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.DataClassBEAN] Could not create entity
java.sql.SQLException: Column count does not match in statement [INSERT INTO DATACLASS (column1, column2, column3, column4, column5, column6, column7, column8, column9, column0, column01) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]

Die Datenklassen sind korrekt gemappt, und die zugehörige Tabelle ebenso, hinzugekommen ist die Spalte für column01 als boolean, welche wie column0 ist und nur einen anderen namen hat, also copy pasta überall ändern und fertig....

aber trotzdem irgendwie nicht funktionierend

 

[FArt]

https://community.jboss.org/message/103696

 

[brauner1990]

--- Dies bezieht sich auf Ex 1 ---

You accessed a stateful session bean within
a transaction, then tried to access it outside
a transaction before commit?

javax.ejb.EJBException: Application Error: tried to enter Stateful bean with different tx context, contextTx: TransactionImpl:XidImpl [FormatId=257, GlobalId=vtsag//227, BranchQual=], methodTx: null

Regards,
Adrian

Ok, soweit war ich auch schon, aber woran kann das liegen?? Wo kann ich das konfigurieren o.ä.



--- Dies bezieht sich auf Ex 3... ---
Die ist gerade viel interessanter ....

ERROR [org.jboss.ejb.plugins.cmp.jdbc.JDBCCreateEntityCommand.DataClassBEAN] Could not create entity
java.sql.SQLException: Column count does not match in statement [INSERT INTO DATACLASS (column1, column2, column3, column4, column5, column6, column7, column8, column9, column0, column01) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)]

 

[FArt]

--- Dies bezieht sich auf Ex 1 ---

Das ist gut, denn so war es auch gemeint.

Ok, soweit war ich auch schon, aber woran kann das liegen?? Wo kann ich das konfigurieren o.ä.

Das hast du leider vergessen zu erwähnen.

Dein Student hat hier leider gegen die Spec verstoßen (EJB 2.0; 7.11.8). Konkurrierende Zugriffe auf ein SFSB sind nicht erlaubt. Das ist ein Designfehler und somit nicht ganz einfach zu beheben.

Theoretisch kann man das lösen, indem man erneut gegen die Spec versößt: man synchronisiert die Methodenzugriffe.Eine technisch nicht ganz einwandreie Lösung und eher im Bereich der Grauzone angesiedelt wäre eine Realisierung über einen Interceptor.

Ich empfehle jedoch, die dortige Logik zu überdenken und das Design sowie dann die Implementierung anzupassen. Verstoße gegen die Spec und damit verbundene Workarounds tendieren stark dazu, sich bei Migrationen auffällig zu verhalten. Diese Synchronisation wäre natürlich ein potentielles Bottleneck. Außerdem kann es sein, dass mal ein Call auf ein SFSB hängen bleibt (z.B. bei einem DB Zugriff). Das wäre im Normalfall nicht so schlimm, hier wären aber alle Calls auf dieses Bean wegen Synchronisation ausgesperrt.

Die ist gerade viel interessanter ....

Das sehe ich nicht so. Sieht nach einem copy/paste Fehler aus. Das obere ist wesentlich interessanter...

 

[brauner1990]

Das hast du leider vergessen zu erwähnen.

korrekt ... sry!

Dein Student hat hier leider gegen die Spec verstoßen (EJB 2.0; 7.11.8). Konkurrierende Zugriffe auf ein SFSB sind nicht erlaubt. Das ist ein Designfehler und somit nicht ganz einfach zu beheben.

Man sollte ihn aufhängen. EJB 2 mit Lomboz war wohl die besten Lösung für die Implementation mit den ganzen Local Home usw....

Theoretisch kann man das lösen, indem man erneut gegen die Spec versößt: man synchronisiert die Methodenzugriffe.Eine technisch nicht ganz einwandreie Lösung und eher im Bereich der Grauzone angesiedelt wäre eine Realisierung über einen Interceptor.

Leider nicht möglich direkt ... Der MVC Thread der da eingebunden ist, greift euf eine Facade zurück, welche wiederum von Lomboz generiert wird.

Ich empfehle jedoch, die dortige Logik zu überdenken und das Design sowie dann die Implementierung anzupassen.

kein Geld für da ... es wurde bereits eine Neuentwicklung / Ent-Lomboz-Ziefizierung angedacht, aber dafür wird mir kein Zeitfenster gewährt.

Diese Synchronisation wäre natürlich ein potentielles Bottleneck. Außerdem kann es sein, dass mal ein Call auf ein SFSB hängen bleibt (z.B. bei einem DB Zugriff).

DB Zugriffe sind viele drin, da es sich um sehr sehr wichtige LIVE Daten handelt, welche nie veraltet sein dürfen. Langsamer wäre ok, aber hängend schlecht.

Das wäre im Normalfall nicht so schlimm, hier wären aber alle Calls auf dieses Bean wegen Synchronisation ausgesperrt.

Ist leider DIE Bean der Applikation


Das sehe ich nicht so. Sieht nach einem copy/paste Fehler aus. Das obere ist wesentlich interessanter...[/QUOTE]

 

[FArt]

EJB 2 mit Lomboz war wohl die besten Lösung für die Implementation mit den ganzen Local Home usw....

Verständlich, EJB2 ist ja auch sehr lästig an vielen Stellen.

Der MVC Thread der da eingebunden ist, greift euf eine Facade zurück, welche wiederum von Lomboz generiert wird.kein Geld für da ... es wurde bereits eine Neuentwicklung / Ent-Lomboz-Ziefizierung angedacht, aber dafür wird mir kein Zeitfenster gewährt.

Das ist ein Problem.

DB Zugriffe sind viele drin, da es sich um sehr sehr wichtige LIVE Daten handelt, welche nie veraltet sein dürfen. Langsamer wäre ok, aber hängend schlecht. Ist leider DIE Bean der Applikation.

Stateful und DIE Bean? Das ist mit größter Wahrscheinlichkeit ein grober Designschnitzer. Dies sollte wohl ein SLSB sein, welches die gewünschten Daten in einer DB hält, evtl. mit einem Cache. Nur so kann auch die Konsistenz der Daten gewährleistet werden. Die aktuelle Implementierung produziert jetzt schon wegen mangelnder Synchronisation inkonsistente Daten, sofern diese Daten zwischen Clients geteilt werden.

Um wie viele EJBs reden wir hier? Ich empfehle eine Migration auf EJB3, dann fallen diese ganzen Fassaden weg. Evtl. auch eine teilweise Migration auf EJB 3 ist denkbar. Die Entity-Beans kann man ja evlt. erst mal lassen... Natürlich sollte auch das SFSB wegfallen bzw. durch ein SLSB ersetzt werden.
Evtl. kann man über eine Untestützung mit den JBoss Tools nachdenken, welche lediglich die Entwicklung vereinfachen aber keinen Einfluss auf die Implementierung haben (im Gegensatz zu Lomboz).

EJB 3.1 ist nicht mehr so restriktiv. Hier wird vom Container verlangt, dass konkurrierende Zugriffe serialisiert, also zueinander synchronisiert werden. Hier funktioniert das (gegenüber der einfachen Synchronisation) aber mit einem Timeout. So einen Interceptor kannst du dir selber bauen (bzw. den von EJB 3 adaptieren). So macht das z.B. der JBoss: GrepCode: org.jboss.ejb3.concurrency.impl.ContainerManagedConcurrencyInterceptor (.java) - Class - Source Code View

Bei vielen konkurrierenden Calls kannst du das aber vergessen!

 

[brauner1990]

Thx, ich werde dies alles mal vortragen und gucken was ich erzählt bekomme

 

[brauner1990]

Also nur mal fyi

Ich habe ein Zeitfenster von 2 Wochen für die volle Migration bekommen, auf zu EJB 3

 

[timbeau]

Und an Manpower 10 Leute?

 

[DerFeivel]

Oder deren Gehalt

 

[FArt]

Also nur mal fyi

Ich habe ein Zeitfenster von 2 Wochen für die volle Migration bekommen, auf zu EJB 3

Zwei Wochen hört sich knapp an, selbst wenn man nur von der reinen Implementierung ausgeht... kommt halt drauf an wie umfangreich die EE Applikation ist (Anzahl EJBs) und was alles umgestellt wird.
Du solltest auf jeden Fall versuchen ohne SFSBs auszukommen.

 

[brauner1990]

Also ich muss ja "nur" die Persistence umstellen, daher gehe ich von 2 Wochen aus...

 

[brauner1990]

Thema nicht erledigt (Problemstellung nicht gelöst), aber eigentlich abgeschlossen ... pls close