Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
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.johanOn 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 occursa) 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 BeanAc) The access of BeanB.getBeanA().getId will throw a LazyInitaliaziationException4. 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 attributesand let the server so the loading in the catch bockb) 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 serverAll 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
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
I want to add some thoughts about how NOT to do it. Its for completeness sake. @entiy class BeanB ... private BeanA; @ManyToOne(fetch=FetchType.LAZY) public BeanA getBeanA() I solved the problem with fetch=FetchType.EAGER. This has a serious impact on performance but it will get you going. c) never do a direct access. Always send the bean back to the server and do the loading on the server I dont know exactly what you mean with this. In our setup we had value objects guarding the beans. Again, this is the way not to do it. We designed for EJB 2.1 and introduced value objects to pass information in and out of beans. Then the client wanted cutting egde EJB 3.0 with an old buggy jboss version. In the end we had (EJB 3.0) stateless beans which used entity beans which returned value objects. So we did not passed the entity bean POJOs but some VOs. Again, dont try this at home. Its for your interest and hopefully for your amusement. Ricky PS Its interesting: I changed nearly all eager statements to lazy statements to evaluate the problem again but its simply working now. I am not sure why or if the situation is not compatible with the given scenario but my application throws no exceptions... --- 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=lnkkid=107521bid=248729dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
We have planned to look at this issue because we also want to use a pure EJB3 implementation. But there are some other issues with the EJB3 specification that makes it almost useless for production applications: - it does not have a simple solution for value converters, so converting for instance a DB char to a Java boolean cannot be done out of the box. - the EJBQL language does not even implement the complete SQL99 standard. One of the important things it misses is a join on sub queries. The solution to this issue might be to use an extended persistence context. Somewhere you must be able to set the PersistenceContextType to EXTENDED. In that case the Entity Beans are not detached when the transaction is closed. You should read chaper 3.3 and chapter 5.7 of the 'Enterprise JavaBeans 3.0, Final Release specification' for more information. I don't have any experience with it so I'm not sure if it has some drawbacks that makes it useless in a Wicket world. -- View this message in context: http://www.nabble.com/EJB3+Lazy+Loading+%28was+%22Seam-like+solution+for+Wicket+%2B+EJB3-%22%29-t1715549.html#a4659930 Sent from the Wicket - User forum at Nabble.com. --- 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=lnkkid=107521bid=248729dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
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=lnkkid=107521bid=248729dat=121642 ___ Wicket-user mailing list
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
I think this is exactly how Seam deals w/ the problemwhat 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 worksor what the best solution for this issue would be. Perhaps it's another, independent framework entirely outside of WicketWicket 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
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
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 problemwhat 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 worksor what the best solution for this issue would be. Perhaps it's another, independent framework entirely outside of WicketWicket 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
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
I've been meaning to take a look at that and I think I will this weekend. I have another internal project here at work I'd like to convert to Wicket (currently uses very crude servlet+JSP MVC approach) - and it uses Hibernate. On 6/1/06, Eelco Hillenius [EMAIL PROTECTED] wrote: 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 problemwhat 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 worksor what the best solution for this issue would be. Perhaps it's another, independent framework entirely outside of WicketWicket 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)
Re: [Wicket-user] EJB3 Lazy Loading (was Seam-like solution for Wicket + EJB3?)
You can't just set all of your collections to be eagerly loaded, that is most definitely *not* the solution...and is in 99% of cases, a bad idea. You're better off doing separate queries for the exact data you need as opposed to eagerly-loading everything + the kitchen sink. You can only eagerly load one collection per entity anyhow...and cannot nest them in child entities...or the latest JBoss EJB3 implementation will barf while deploying your app. We're getting somewhat off-topic here, however and we should focus on a Wicket-specific solution to rival Seam's ability to make transparent access to lazily-loaded collections for JSF. On Thu, 2006-06-01 at 13:00 +0200, Ricky wrote: I want to add some thoughts about how NOT to do it. Its for completeness sake. @entiy class BeanB ... private BeanA; @ManyToOne(fetch=FetchType.LAZY) public BeanA getBeanA() I solved the problem with fetch=FetchType.EAGER. This has a serious impact on performance but it will get you going. c) never do a direct access. Always send the bean back to the server and do the loading on the server I dont know exactly what you mean with this. In our setup we had value objects guarding the beans. Again, this is the way not to do it. We designed for EJB 2.1 and introduced value objects to pass information in and out of beans. Then the client wanted cutting egde EJB 3.0 with an old buggy jboss version. In the end we had (EJB 3.0) stateless beans which used entity beans which returned value objects. So we did not passed the entity bean POJOs but some VOs. Again, dont try this at home. Its for your interest and hopefully for your amusement. Ricky PS Its interesting: I changed nearly all eager statements to lazy statements to evaluate the problem again but its simply working now. I am not sure why or if the situation is not compatible with the given scenario but my application throws no exceptions... --- 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=lnkkid=107521bid=248729dat=121642 ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
