• Post Reply Bookmark Topic Watch Topic
  • New Topic

CMP EJB and large data sets returned by finder methods

 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

Does anyone have any info on whether or not CMP is apt for pulling out large(ish) numbers of records from the underlying data store?

We have a problem deploying on Weblogic, but after much investigation and research, we're hearing that CMP is just not suited to pulling out bulk data.

This is in the order of 1000 - 10000 records with one finder query. This doesn't seem like a great deal to me, but we've had significant problems (specifically, CacheFullExceptions from Weblogic; I posted a question on this in the Weblogic forum here). Is this inherent to EJB or are we doing something wrong?

Any advice / article links much appreciated.



--Tim
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tim West:

we're hearing that CMP is just not suited to pulling out bulk data.


I agree. If your deployment environment has tons of memory, then you can still afford to have finders that pull out large amounts of data.

Are you pulling out this data for tabular display / something. If that is the case, I w'd suggest use jdbc. We actually had a home grown framework that did that using jdbc. It was very simple to configure etc.

When using Entity beans make sure that your code actually works with the customer data, i mean large scale data. Do ask questions on usage patterns and what kind(amount) of data they expect on each of the entities you have modelled. Once you have the feedback, quickly assemble a dataset that models the production scenario. Eveything works when the data is minimal, but once the code goes into production, you might be in for some surprises.
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We don't just display it, we need to pull out certain values. In any case JDBC may be better, but it's only very rare cases that actually present this problem.

In any case I have proven (to myself at least) that it's something to do with the session layer: I wrote a quick JSP that talks straight to the bean, and it loads the data with no problems. Now I'm going to point it at my DAO and see it if it works there (which it will: the DAO just wraps the bean). Then, it's either session facade or delegate. We will see!

My hunch is now that it's to do with Weblogic transaction handling. I'll leave this post here and continue my ranting in the Weblogic forum.

Cheers,



--Tim
 
Karthik Guru
Ranch Hand
Posts: 1209
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IMHO, Entity bean technology works. But you need to be aware of app server specific features to make it work. You might have to endure enough pain to get it to work, and then you start wondering if it was really worth the effort.

If you are just looking for transparent persistance and if you are still in the initial stages of development then my suggestion w'd be to abandon entity beans and check out other ORM tools. As is the recommened practice, use them behind a session facade.
 
Tim West
Ranch Hand
Posts: 539
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
LOL. The system goes live starting 2PM tomorrow...so there won't be many changes now

This is more of an academic question, since the 2000 rows only came up in a load testing scenario that won't occur in real life. Still, there are a lot of changes outstanding and we'll probably put a fix for this in a future incremental release.

I do want to work it out now - it's become one of those issues that you just gotta understand. I'm gonna do some more testing and then find a more appropriate Weblogic forum to query. We've got some good Weblogic guys on the team but none of them have seen this issue before.


--Tim
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!