[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2590) EntityQuery components hold the whole untruncated resultset if maxResults property is set and the underlying dialect does not support limits
by vargadan (JIRA)
EntityQuery components hold the whole untruncated resultset if maxResults property is set and the underlying dialect does not support limits
---------------------------------------------------------------------------------------------------------------------------------------------
Key: JBSEAM-2590
URL: http://jira.jboss.com/jira/browse/JBSEAM-2590
Project: JBoss Seam
Issue Type: Bug
Components: Framework
Affects Versions: 2.0.1.GA
Reporter: vargadan
If the dialect supports limits then query objects only hold the number of rows set by the maxResults property.
So i.e. if the search results 10000 rows but the page size is 10, only 10 objects are kept.
But if the dialect does not support limits (like derby) then truncation of the result list in done in EntityQuery.getResultList() which in the previous example results in the following:
- 10000 objects are kept in EntityQuery.resultList
- only 10 of them is displayed in one page
- EntityQuery.getResultList() returns EntityQuery.resultList the sublist every time when invoked
- when paginating the query is executed for every page, so there is no point in holding all the rows.
It causes quite a big overhead when query components are kept in conversation scope, which is the case most of the times.
If the truncation was done just after querying against the DB, there would not be such an overhead.
I.e. Query.truncResultList gets invoked in EntityQuery.initResultList and EntityQuery.resultList holds only the truncated list of results.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months
[jbossseam-issues] [JBoss JIRA] Created: (JBSEAM-2430) JNDI lookup error when injecting a stateful bean into a stateful bean in glassfish
by Richard Hoffman (JIRA)
JNDI lookup error when injecting a stateful bean into a stateful bean in glassfish
----------------------------------------------------------------------------------
Key: JBSEAM-2430
URL: http://jira.jboss.com/jira/browse/JBSEAM-2430
Project: JBoss Seam
Issue Type: Bug
Reporter: Richard Hoffman
Per Pete's request (http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4115521#4115521) I'm making a ticket about the problem I'm facing:
Using glassfish, I'm trying to inject a stateful bean into a stateful bean...instead of describing my specific app and trying to explain exactly what I'm doing and why, I figured I'd demonstrate how to duplicate my problem using the jee5/booking example provided with Seam 2:
1.) Add the following to the top of HotelSearchingAction:
import org.jboss.seam.annotations.In;
.
.
@In(create=true)
private HotelBooking hotelBooking;
2.) Redeploy and run the booking app.
3.) Navigate to the Search page. You should receive a "Could not instantiate Seam component: hotelBooking" error, which is caused by: "javax.naming.NameNotFoundException: No object bound to name java:comp/env/jboss-seam-jee5/HotelBookingAction/local"
Now, granted, in this particular case, there really isn't any functional reason to do this injection, but it demonstrates the same problem I'm having on my particular application (where this kind of injection makes sense). It is also worth noting that if you do the opposite injection (HotelSearching into HotelBookingAction), you have no problems.
One way I found to get around this problem is to put a @Startup at the top of the HotelBookingAction bean, but I'm not sure why this is necessary.
---
My theory as to what's going on is as follows...my apologies if I'm way off, heh:
The page flow of the booking app is Login -> Search (which uses HotelSearchingAction) -> Book Hotel (which uses HotelBookingAction). So, HotelSearchingAction gets (instantiated?) put in the JNDI tree first, as the user progresses through the app. The problem is, when you inject HotelBookingAction into HotelSearchingAction, HotelBookingAction needs to be created when HotelSearchingAction is first used, but it hasn't been put in the JNDI tree yet, so we get a lookup error. And of course, if you put @Startup on HotelBookingAction, HotelBookingAction is now in the JNDI tree way before HotelSearchingAction needs it, so the error is gone. But again, I'm not sure why @Startup should be necessary to inject a not-yet-used stateful bean into a stateful bean.
Thanks in advance to anyone who works on this ticket. :-)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years, 8 months