# EJB 2.0



## brauner1990 (10. Jul 2012)

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 (10. Jul 2012)

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


----------



## brauner1990 (10. Jul 2012)

```
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 (11. Jul 2012)

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


----------



## brauner1990 (11. Jul 2012)

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



			
				aus 'https://community.jboss.org/message/103696' - erste und einzige Antwort hat gesagt.:
			
		

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



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 (12. Jul 2012)

brauner1990 hat gesagt.:


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


Das ist gut, denn so war es auch gemeint.



brauner1990 hat gesagt.:


> 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.



brauner1990 hat gesagt.:


> Die ist gerade viel interessanter ....


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


----------



## brauner1990 (12. Jul 2012)

FArt hat gesagt.:


> Das hast du leider vergessen zu erwähnen.


korrekt ... sry!





FArt hat gesagt.:


> 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.... 





FArt hat gesagt.:


> 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.





FArt hat gesagt.:


> 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.





FArt hat gesagt.:


> 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. 





FArt hat gesagt.:


> 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 (12. Jul 2012)

brauner1990 hat gesagt.:


> 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.



brauner1990 hat gesagt.:


> 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.



brauner1990 hat gesagt.:


> 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 (12. Jul 2012)

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


----------



## brauner1990 (16. Jul 2012)

Also nur mal fyi

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


----------



## timbeau (16. Jul 2012)

Und an Manpower 10 Leute?


----------



## DerFeivel (17. Jul 2012)

Oder deren Gehalt


----------



## FArt (17. Jul 2012)

brauner1990 hat gesagt.:


> 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 (17. Jul 2012)

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


----------



## brauner1990 (23. Jul 2012)

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


----------

