Fast Lane Reader (to read) + CMP (to wirte)

I use 'Fast Lane Reader'(Stateless Session + DAO) to read a list of CreditCards(for example, assume i've 100's of cards). I go thru the list of credit cards and select one to modify. To modify, I use CMP Enity Bean. Basically, I call the finder method & modify creditcard.

(This is not related to assignment).

Any, expert comment on this approach..?

Thanks.

[ November 14, 2005: Message edited by: mark antony ]
[ November 14, 2005: Message edited by: mark antony ]

CMP not just for writing,if the query result will not create too many entity you also can use CMP.

Originally posted by chao cai:
CMP not just for writing,if the query result will not create too many entity you also can use CMP.

But that's the entire point of the fast lane reader - to process a single query that returns a number of records that exceeds the number of beans in the pool many times over.
Fast Lane Reader

Originally posted by mark antony:
Any, expert comment on this approach..?

I'm no "expert" but the Fast Lane Reader gives me the impression of "pre-mature optimization" as you may be committing to increased design (and implementation) complexity without sufficient evidence that the less complex solution is performant enough. If I were in your shoes I would proceed in the following manner.

Create the design so that a fast Lane Reader can be dropped in if necessary.

Create the CMP Entity Bean (you are going to need it anyway).

Create a profiling/testing setup that forces a scenario where an extremely large number of records have to be processed. Profile for real time, CPU time and other server resources.

Do a profiling run to assess the performance.

Now find the SQL SELECT statement(s) that is cost-optimal with your RDBMS/Datamodel. (Your are going to need this work for the Fast Lane Reader any way). Research your application server to determine if you can influence the SQL it will generate - you may be able to tell it exactly the SQL it should be using.

Do another profiling run to assess the current performance.

Do profiling runs with various entity bean pool sizes to determine how that effects performance.

Create a serializable class that can hold the relevant row details you need for your processing (a Transfer Object really; but nobody is stopping you putting convenience methods on it).

Create a Home Business Method to return a collection of these TOs. That home business method would use a Select method - which, if possible, you provide with an optimized SQL Query.

Do another profiling run to assess the current performance.

At this point you may already have most of the benefits of the Fast Lane Reader, while minimizing the impact on your design/implementation.

The additional complexity of the Fast Lane Reader is probably warranted if you have to process a result set of millions of rows. In that case you do not want to load the entire result set at once but instead fetch the rows from the RDBMS server in batches and start processing while there are still rows from the result set on the RDBMS server.

>I use 'Fast Lane Reader'(Stateless Session + DAO) to read a list of >CreditCards(for example, assume i've 100's of cards). I go thru the list of >credit cards and select one to modify. To modify, I use CMP Enity Bean. >Basically, I call the finder method & modify creditcard.

From my experience it's better not to use CMP beans for bulk reading and searching, indeed. Entity beans (before EJB 3.0) are too heavy for this and you can run into scalability and performance problems very soon. But it's ok to use Hibernate.

I can tell you that without any profiling.

I know one case where some stupid guys created J2EE system where they used CMP beans to read and search data. With real data (large number or records) the system didnt work at all.

Customer decided to throw the system away and later it was rewritten in .NET.

Just imagine, you can have thousands of credit cards in db - with CMP's the server creates thousands of objects every time you need to display a small list of cards. Of course, it wouldnt work. Get real !

Originally posted by Maris Orbidans:
I know one case where some stupid guys created J2EE system where they used CMP beans to read and search data. With real data (large number or records) the system didnt work at all.
Customer decided to throw the system away and later it was rewritten in .NET.

Well those same "stupid guys" would cock it up the same way under .NET - they didn't take enough time to understand the platform and research critical appraisals that outlined its strengths and weaknesses. There is not reason to believe that they would correct that oversight on the next platform.

Originally posted by Maris Orbidans:
Just imagine, you can have thousands of credit cards in db - with CMP's the server creates thousands of objects every time you need to display a small list of cards. Of course, it wouldnt work. Get real !

You do of course understand that the Home Business Method I proposed doesn't actually return any Entity Bean references and it uses only one entity bean in the pooled state? Also the original poster was talking about hundreds - that not even a thousand or tens of thousands.

The biggest problem is EJB-QL's inability to declare more than one single SELECT expression - but you could work around that by using the CONCAT string function to assemble the necessary information.

It would be better (but less portable) to use the resource manager directly in the Home Business Method to create the TOs.

Expert One-on-One J2EE Design and Development (p.300):
An entity bean with CMP is not restricted from performing resource manager access; it has merely chosen to leave most persistence operations to the container.

Originally posted by Maris Orbidans:
From my experience it's better not to use CMP beans for bulk reading and searching, indeed. Entity beans (before EJB 3.0) are too heavy for this and you can run into scalability and performance problems very soon. But it's ok to use Hibernate.

Once again, I wasn't proposing to use "CMP beans for bulk reading and searching" :roll: . I was merely pointing out that there are some areas in EJB that can be exploited before moving to a full blown implementation of the Fast Lane reader.

However, if you are working with a mostly read-only system, use of EJB (pre-3.0) must be questioned (example: Web Customer application of the Java Adventure Builder only uses DAOs; no EJBs in sight). If you only need EJB services that can be provided by simpler frameworks then use of EJB (pre-3.0) must be questioned. For many applications iBatis or Hibernate are more than enough.
However existing applications that already use EJB 2.1 can be optimized to a certain extent, its usually unnecessary to "throw out the baby with the bath water".

Peer, Thanks a lot for your expert suggestion.
Thank you, Maris.

Peer,
I think you are suggesting me to get a list of credit cards from "Home Business Methods". Assume that CreditCard has a reference to Address object (billing). I think it is not a good idea to get list of credit cards thru home business method. Please share your thoughts.

Thanks.

Originally posted by mark antony:
Peer,
I think you are suggesting me to get a list of credit cards from "Home Business Methods". Assume that CreditCard has a reference to Address object (billing). I think it is not a good idea to get list of credit cards thru home business method. Please share your thoughts.
Thanks.

Create a transfer/value object that contains all the info (include the address info (not just a reference) if you need it) you need to decide whether or not to modify the actual entity (include the primary key info of course).

Create a Home Business Method that returns a (relevant) collection of these value objects. Either use a select method that returns the info as a delimited string (and parse it) or go through JDBC directly to keep the field info intact. Even though the home business method by-passes the CMP bean, it still remains part of your home/component interface/bean implementation.

When you go through the collection and determine that you need to modify a CC, use the primary key store in the TO to retrieve the real CMP bean.

Question is: could you actually formulate a SQL query that would simply return to you the all the entities that need to be modified anyway?

I could do this technically. But, I don't think it's a good design choice to make home business method heavy-weight/complex. I think Fast Lane Reader is simple and a better choice to read.
Any thoughts?