? jboss doesn't scale well with lots of entity bean

[edwu00]

Hi, all:

I am populating a large amount of data
with CMP entity bean, at least 20000 entity beans.
It runs fast at beginning, but it begins slow down.
when I populate until 2000, the JBoss
throws an exception possibly time out.
The transaction is rolled back.

1) If JBoss doesn't handle large amount of beans,
How can I control when a transaction begins and
when it ends in CMP managed beans? eg. commit 1000
beans first and then create 1000 beans and commit
again.
2) But I still need to have only one transaction
that commit large amount of data? What's the
final solution?

Thank you very much.

Ed Wu

[dsundstrom]

What version are you using?

Based on the information about you specific problem. I would recommend using a Stateless Session bean with bean managed transactions for your batch import. This way you can exactly control the size of the import batch. If you don't know how to use bean managed transactions I would buy the O'Reilly EJB book. As a side not, your database may the culprit here. Some databases have problems with huge ammonites of data in an uncommitted transaction.

[edwu00]

Thanks for the reply.
I am using this version:
JBoss-2.4.1_Tomcat-3.2.3

Is it possible to remove an entity
object without destroy the data in
the database?

Thanks.

Ed Wu

[andreas]

Increase the max cached beans in standartjboss.xml
<cache-policy-conf>
...
<max-capacity>20000</max-capacity>

and increase the transaction timeout in jboss.jcml

[janheise]

an entity-bean and the row in the table of your db are the same. the one does not exist without the other.

[rakhbari]

This is one area where CMP won't do. I have an exact same requirement that when ejbRemove() is called on one of my EBs I want the record tagged as "deleted" but I don't want the row removed from the DB. This is an instance where you have to resort to A BMP EB.

Ramin

[ninki]

Ramin,
One trick/pattern we often use is to have a history table. When an insert is done on the main table, a copy is written to the history table via a trigger. There's also a trigger on update and delete. The history table needs two extra columns, valid_from and valid_to timestamp. This is handy for auditing and data warehousing. Also, the main table is kept small, and at least with Oracle, you can have the history table in another DB, with lots of extra indicies, etc...
Ciao,
Ninki