It doesn't matter if the Web-Layer is on a separate machin eor VM, it just depends on the availability of a PersistenceContext, which is, in all cases i encountered so far, equivalent to a EJB-Transaction. I.e., while in a transaction, you are free to call /load any relations, w/o getting nasty errors. So if you don't use a Client-UserTransaction (which is possible, but not recommended), a call to any SessionBean which returns any bean will implicitly starts a transaction and closes it when the method returns.
So in order to have a "seam-like" behaviour, we should look at the EJB3 "Extended" PersistenceContext, that somehow allows re-attaching beans (sorry, didn't use that stuff yet, so no experiences). But still, for performance and concurrency reasons, the main point is: *When do i start/end my transactions* One might be tempted (as i was) to just wrap the whole requestcycle into one transaction. That works fine, almost no headaches with lazy loading, but really doesn't scale because transactions last too long. So what i do right now is to have a layer of sepcialized gui-related SessionBeans that return *completely initialized* beans, i.e. beans that already have any collection loaded that will be needed in the page. This is, of course, a pain in the a.., but right now i don't see any other solution... Marco Johan Compagner wrote: > What is that "client" where you talk about? Do you have a App server that > contains the EJB and a App/Web server == client? that runs wicket? > > Why does this happen: > > Now if an Instance of BeanB is passed to a wicket component the following > occurs > a) The BeanB instance is detached from the transaction context of the > app server. There is no way to avoid this. > > ?? If i ask the persistence layer for BeanB does it open a session get B > close the session and then return B? > > that would be awfull. > > johan > > > On 6/1/06, Stefan Lindner <[EMAIL PROTECTED]> wrote: > >> >> Dear suffering lazy loaders, >> >> I want to start a new thread with a discussion that is focused on EJB3 >> (not Spring, not Hibernate) because all those "In Hibernate it works like >> this..." hints are not helpful. To clearyfy this: >> 1. EJB3 is NOT Hibernate. Yes, the EJB3 implementation of JBoss is based >> upon Hibernate but other vendors do NOT use Hibernate. >> 2. Since Wicket is platform independent, an EJB3 solution for Wicket >> should be independent too. >> 3. The Problem arises when a Bean references another bean as an object >> through a relation: For Example >> >> SQL: >> create table A (id integer, value varchar(100) >> create table B (id integer, value varchar(100), ref_to_a integer) >> alter table B add constraint ArefB ref_to_a references A(id) >> >> JAVA >> @entity >> class BeanA .... >> public int getId() >> public void setId() >> >> @entiy >> class BeanB ... >> private BeanA; >> @ManyToOne(fetch=FetchType.LAZY) >> public BeanA getBeanA() >> >> Now if an Instance of BeanB is passed to a wicket component the >> following occurs >> a) The BeanB instance is detached from the transaction context of the >> app server. There is no way to avoid this. >> b) The instance of BeanB does not contain a complete BeanA >> c) The access of BeanB.getBeanA().getId will throw a >> LazyInitaliaziationException >> >> 4. It is not possible (correct me if I am wrong) to have a EJB3 >> transaction on the client. This means it is not possible to bring back >> the >> BeanB instance into an attached state on the client. >> 5. The only solutions I can see may be the following: >> a) Find some way of putting an interceptor in the access method for >> lazy loades attributes and let the server so the loading in the catch >> bock >> b) Wrap a try/catch block around the access and let the server so the >> loading in the catch bock >> c) never do a direct access. Always send the bean back to the server >> and do the loading on the server >> >> All three solutions need the server to do the lazy loading. >> 6. Just to clearify: Not Wicket is the problem. The problem lies in the >> design of EJB3 lazy loading itself. Any client application has the same >> problem in principal. >> >> Is this correct until this point? Only after we come to a clear >> definition >> of the problem we may find a way to solve it. Any suggests are welcome. >> Please help us to use wicket and EJB3 in a better way. >> >> Stefan Lindner >> >> > -- ___________________________ Dipl.-Ing. Marco Geier EyeTea GmbH Germany phone +49 (0)721 662464-0 fax +49 (0)721 662464-1 mobile +49 (0)177 6579590 [EMAIL PROTECTED] ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 _______________________________________________ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
