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
