Think of the following scenario:
Customer has a shopping cart with 1000 items. We have stored the cart in our database (1 + 1000 rows). (I know! We don't have to but...)
Suddenly the Customer decides to NOT buy anything and deletes the shopping cart.
We take care of the event by fetching the cart and the 1000 items. Removing the items one by one and finally the cart. It was 1001 database calls. In a system with some other persistence mechanism than EJB we would have used 2 (two) database calls.
I think this is stupid and that the standard must include features for multiple removes and updates in the same way as you can declare finder methods for multiple objects.
If you require Bulk removes, inserts, you can create an Entity Bean with those characteristics and then provide the necessary persistence logic to carry out those tasks.
A mistake many EJB designers make is that they only create Entity Beans that represent ONE piece of data -- or one row. It is relatively simple to add another Entity Bean which represents many rows, or many sets of PKs.
That way, when you do a remove, you can call the remove of the 'Bulk' object which instead of doing the SQL equivalent of 'delete from x where xid = :?', it would do something like this: 'delete from x where xid in (:?, :?, :?, ... )'. Much more preferred for performance reasons.
Although generally (as you pointed out), carts should not be stored in the database until the person actually places the order. But there definitely are justifiable reasons for doing this sometimes.
I am confused,what that "bulk delete capable " entity means?
It is better to do all the bulk access operations in the
Be careful about potential transaction/locking issues.
I agree. But the idea is to be able to delete 1000s of rows in a table with a 'criteria'. Very similar to the fetchByXxxxx. In this case, we'd want something like a removeByXxxx.
A Bulk Entity Bean can give this kind of functionality.
At times (for performance/efficiency reasons) there is a need to do the following in SQL:
"delete from Table where TableID in (?, ?, ?, ?, ?, ?, ...)"
Using a basic EJB entity bean, the container would loop for each PK making a roundtrip to the database. VERY inefficient for large numbers of deletes.
That's what we're talking about.
I still didn't get it,
what is the Bulk Entity Bean stand for?
It is relatively simple to add another Entity Bean which represents many rows, or many sets of PKs.
so the bulk entity bean will coexist with individual
I am not sure if it is the right way to use EJB, you have
two EB stand for the same piece of data, how you
control the lifecycle.e.g. what you put in the
Is removeByXxxx a business method?If that is the case,why
not create a session bean instead?That is a more clear
It really depends on how you are going to use your data. I don't think that writing a session bean to do bulk deletes is a good thing. Mainly because I don't think that any persistence logic belongs within a session bean.
The bulk bean itself is an Entity bean that really only contains a collection of rows it represents. In data object terms, it is like this:
public class Person
public long SSN;
public String firstName;
public String lastName;
public class BulkPerson
public List persons;
/* OR */
public PersonData persons
Now, in my ejbRemove() method (and I *always* use BMP, not CMP), I would have code like the following:
String lSQL = "delete from Person where SSN in (?, ?, ?, ?, ?, as many as # of persons)";
PreparedStatement pstmt = connection.prepareStatement(lSQL);
int lIndex = 0;
for (int i = 0; i < persons.length; i++)
Of course, you also need to have synchronization and locking to ensure concurrency -- nobody else is using a Person that you are deleting. After the delete, the Person EJBs would also have to be refreshed if they are cached. In order to reflect the current image of the DB.
Really though, we are talking about one of the severe lackings in EJB. This is one of many reasons that I refuse to use EJB entity beans -- however, I will use session beans.
Hopefully, the EJB spec will evolve over time and become much more user-friendly and efficient in the future.
My point was that there should be a possiblity to declare a removeByXXXX in the same way that I can declare a findByXXX.
I am using weblogic CMP and this issue came up.
Another example is when you have an object with a lot of relations to it. Then you have to remove all the relations before you can remove the object. For instance could 1000 shopping cart items have FK to an article wich shall be removed. It would be nice to use some standard declaration and get good performance and as little code as possible for this simple task.
Currently I use a stored procedure and get very good performance but that will never be the standard portable way. Simple tasks like this usually will be part of the standard. Will it?
The EJB-standard must include "standard" ways to do simple tasks if they are simple tasks if you do not use EJB.
When I discuss this I usually get hints about triggers, cascade deletes and such stuff. But how about the containers caching mechanisms?
My point was that there should be a possiblity to declare a removeByXXXX in the same way that I can declare a findByXXX?
It is nice, but the question is whether current EJB spec
Rick, I am new to EJB. would u mind elaborating a bit more on following
"A mistake many EJB designers make is that they only create Entity Beans that represent ONE piece of data -- or one row. It is relatively simple to add another Entity Bean which represents many rows, or many sets of PKs. "
The pattern that session bean do the bulk processing can
be found at j2ee blueprint:
How can I a multiple ejbCreate changing some values between insertions?
The problem that you have encountered is a limitation of CMP in the EJB 1.1 specification. The suggestions made by others to handle this require handling your own database interaction through BMP or a session bean.
The EJB 2.0 spec does include mechanisms for handling these types of "simple" tasks (including a cascasing delete mechanism where when the shopping cart is deleted, all of the contents will be deleted as well).