Let's talk about Flex, AIR, ActionScript, ColdFusion and more    

LCDS+CF DataManagement scalability is very very small




If there are huge data in target table, Java heap error happens. Even if you call fill method with parameters, Java heap error happens if the result data has many recordset.

# I tested by one million data or more.

Also it loads all data into Flex app on sort. You know it eats huge memory resource.

LCDS + CF DataManagement scalability is very very small. Don't use it with large data. Also there are a couple of critical bugs. The quality is not enough for real business. You'll have many troubles.


Comments
Henry Ho's Gravatar Wow.. is that true? Maybe there are other ways to handle large data set??
# Posted By Henry Ho | 3/6/09 12:37 PM
Brian Kotek's Gravatar First, the version of LCDS that ships with CF is licensed for only one CPU. So doing anything involving a million objects on one CPU is a very bad idea.

Second, under the hood this is using CFCs, and trying to do anything involving a million CFCs is also a very bad idea.

Third, you're using client-to-server paging, which loads the entire data set into memory. For a million objects, that's totally inappropriate. You should be using server-to-data paging, which loads the data on an as-needed basis.

As an aside, drop the number of letters in your captcha. 8 letters is going too far.
# Posted By Brian Kotek | 3/6/09 1:02 PM
Shigeru's Gravatar > Brian Kotek
Huh, so I said "LCDS+CF DataManagement scalability is very very small". There is no way to control paging at CF side. The CFC of assembler doesn't have page method and only LCDS controls paging.

Also you know the benefits to use LCDS DataManagement . What you are talking about is "You can't use LCDS DataManagement with such huge data". It's same as my opinion.
# Posted By Shigeru | 3/6/09 1:30 PM
Brian Kotek's Gravatar I'm saying you can use LCDS with huge sets of data with no problem.

You just can't use it with huge data sets on a single CPU license, using CFCs as the data objects, and using the simplified assemblers that CF exposes. I would hope that this doesn't come as a surprise to anyone.

I was under the impression that you were upset that you couldn't easily page through a million records on CF with the single-CPU LCDS. I'm hoping it's self-evident now why that is the case? But if I misunderstood you and you were just posting to make sure everyone else knows not try try and do this, then while I think that's really stating the obvious, I completely agree.
# Posted By Brian Kotek | 3/6/09 2:22 PM
Shigeru's Gravatar I think this is not the problem of hardware spec but the problem of software architecture. Even if we use super spec hardwares with multi-CPU licenses, all data are loaded into Flex/AIR app.

My image is pointing the following problems.
1. It can't control paging at CF side.
2. All data are loaded on sort.
# Posted By Shigeru | 3/6/09 3:38 PM
Brian Kotek's Gravatar Do you have paging enabled in your data-management-config.xml?
# Posted By Brian Kotek | 3/6/09 3:48 PM
Shigeru's Gravatar Yes. And it's setting only at LCDS side. You better check the number of data at fill method of CF side. Also you know there is no "page" method in assembler CFC.
# Posted By Shigeru | 3/6/09 3:59 PM
Brian Kotek's Gravatar If it loads the entire data set into the grid when it is sorted, then yes, I'll be the first to agree that it's a major flaw. But you're missing the point: you simply can't load up a million database rows into server memory, and then add CFC overhead on top of that. Yes, you're right, don't load a million rows of data into CF and the single-CPU LCDS. I guess I'm not sure what to tell you except you're stating the obvious. Saying this is in the same ballpark as saying "if you try to resize a million bitmap images the server will run out of RAM".

I'm agreeing with you, I just think I'm missing the reason why this is somehow startling to anyone?
# Posted By Brian Kotek | 3/6/09 4:41 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.005.