Maybe Nathan's DataBinder project could serve as a starting point there?
Eelco On 6/1/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
I think this is exactly how Seam deals w/ the "problem"....what I don't understand is then; why would they be pushing it as an "enterprise" solution for JSF + EJB3? If it wouldn't scale, assuming this is how Seam works, then it would be useless in a high-concurrency environment. Also, JBoss is pushing for a new JSR standard called "Web Beans" based on the work they've done w/ Seam...so there must be a lot we're assuming incorrectly about how Seam works....or what the best solution for this issue would be. Perhaps it's another, independent framework entirely outside of Wicket....Wicket really isn't the issue (though it'd be nice to have a clean, simple, transparent solution that Wicket could use...it'd make it all the more appealing for large EJB3-based projects!) On 6/1/06, Marco Geier <[EMAIL PROTECTED]> wrote: > 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 > ------------------------------------------------------- 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
------------------------------------------------------- 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
