Ahh yes...I've seen that done too but couldn't figure out how that would be any different than eager fetching?I have seen that trick before but wasn't sure if that was the best approach since I don't *always* want the collection (but would have it since I'm "preloading" before it gets to the view.)
"preloading" is basically just calling "mybean.getMyCollection().size()"
while you still have a session context. (i.e. either in an ejb session
bean or for a example in your Wicket page constructor, given that you
wrapped the eventhandling phase in a usertransaction.
This approach feels a little bi
So, when I reference these persistent child collections, won't they
also need to be wrapped in a detachable model, i.e. when they're
passed to a ListView? Or, because they're child objects of an already
detachable model, are they detached?
On 4/11/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> ah
That'd basically require me to re-write my application and do
everything in an entirely different way...and I'd rather just deal w/
eager fetching and limit the number of records I'm calling instead.
Since I'm using the EJB3 EntityManager I don't want to have to resort
to touching the Hibernate de
you can have a filter that opens AND closes the session/transaction. keep it in a threadlocal, and a base dao that retrieves it from the threadlocal. you can also keep rollback flag in the threadlocal so the filter knows if it needs to rollback or commit the transaction.
hibernate 3 also has the se
you can have a filter that opens AND closes the session/transaction. keep it in a threadlocal, and a base dao that retrieves it from the threadlocal. you can also keep rollback flag in the threadlocal so the filter knows if it needs to rollback or commit the transaction.
hibernate 3 also has the se
Ugh...I thought once I started using a container this issue would go
away...that was the one thing that made setting up Hibernate a
PITAmanaging the frickin' session context (I thought it was really
ugly to open the session in the DAO and close it in a filter...with no
real control over the tra
you could wrap a transaction around the render phase)
(and also around the event processing phase, or both, depending on your
RenderStrategy)
The key is:
UserTransaction ut = (UserTransaction) new
InitialContext().lookup("java:comp/UserTransaction");
But you may need to reattach beans to the se
well, this is a basic requirement and should be part of the ejb spec somewhere.-IgorOn 4/11/06, Vincent Jenks <
[EMAIL PROTECTED]> wrote:Yes...if I were using plain Hibernate and not EJB3...like I explained
in my first post. I need another way of making this work (as Igorsaid...a way to keep the s
Yes...if I were using plain Hibernate and not EJB3...like I explained
in my first post. I need another way of making this work (as Igor
said...a way to keep the session open somehow in the container) - a
way that wouldn't require any Hibernate-specific coding...
I've built several plain Hibernate
You need Open Session In View --> http://www.hibernate.org/43.htmlOn 4/11/06, Igor Vaynberg <
[EMAIL PROTECTED]> wrote:in that case your container's persistence mechanism is closing the underlying hibernate session after the end of the invocation? this is a container specific problem not a wicket o
in that case your container's persistence mechanism is closing the underlying hibernate session after the end of the invocation? this is a container specific problem not a wicket one. you need to figure out how to tell your container to keep the underlying entity manager session open so that lazy c
I changed the param to look like yours:
new PropertyModel(blogModel, "categories")
...and I get the same exception...no luck!
On 4/11/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> you are still not using a model for the listview, you are binding the
> listview to hibernate's lazy initializable
you are still not using a model for the listview, you are binding the listview to hibernate's lazy initializable set instead in this line:add(new ListView("categoriesView", ((Blog)getModelObject())
.getCategories())try changing that to:add(new ListView("categoriesView", new PropertyModel(blogModel,
OK, this doesn't appear to work. I finally got around to testing this
and I still get a
LazyInitializationException.
I passed the model around and it's barfing.
"main" page (ViewBlog.class):
//get object graph in detachable model
IModel blogModel = new LoadableDe
this usecase will be much better when we release 2.0EditProductPage(IModel) is not nearly as nice as EditProductPage(IModel)-IgorOn 3/20/06,
Igor Vaynberg <[EMAIL PROTECTED]> wrote:
or pass the same model :) -IgorOn 3/20/06,
Vincent Jenks <[EMAIL PROTECTED]> wrote:
Well, in the previous page whic
or pass the same model :) -IgorOn 3/20/06, Vincent Jenks <[EMAIL PROTECTED]> wrote:
Well, in the previous page which passes the Product into this page...the object was wrapped in a detachable model...not just called directly...so I should try and wrap it again in the current page?
On 3/20/06, Igor
Well, in the previous page which passes the Product into this page...the object was wrapped in a detachable model...not just called directly...so I should try and wrap it again in the current page?
On 3/20/06, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
instead of using the product object directly, us
instead of using the product object directly, use a detachable model.you might also need to use an open session in view interceptor in case jboss closes the hibernate session after your bean's method is finished executing. if it does this, then by the time wicket code runs the object is already dis
OK, so I'm in a bit of a quagmire.I'm using Wicket + EJB3 (JBoss 4.0.4RC1) which uses Hibernate as the persistence behind EJB3.Unless I set all of my parent/child object relationship annotations to EAGER fetching...I get this error:
"org.hibernate.LazyInitializationException: failed to lazily initi
20 matches
Mail list logo
