Does OO fit this? [closed] - performance

Question

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have this process where in one table we have a series of item movements that are to be
applied to the other table with items & stocks. Basically, the item movements table is mapped by the following Entity:
public class ItemMovement {
enum ItemMovementStatus { NEW, APPLIED }
private Long movementId;
private String itemName;
private String itemCategory;
private String arbitraryQualifier;
private Date movementDate;
private ItemMovementStatus status;
// getters & setters
}
The inventory item entity is like this:
public class InventoryItem {
private String itemName;
private Double itemStock;
private String arbitraryQualifier;
// getters & setters
}
Movements are generated in the course of a month, at the end of which all the movements must be "applied" to the inventory table. "Applying" a movement means essentially substracting the ITEM_MOVEMENT_QTY for every given movement from the STOCK value of the inventory table where an exact match exists. If an exact match exists with at least the required movement quantity, the job is done. If not, we just take what we can and continue taking now from another item which falls into the same ITEM_CATEGORY. If this last inventory item did not have enough to complete the requested movement quantity we must take from inventory items that share the same ARBITRARY_QUALIFIER that the movement item has.
The problem with this last is that, matches for this ARBITRARY_QUALIFIER can go from hundreds or even thousands of "matches" per movement item, because, as it names implies, this qualifier can relate two "totally" unrelated items. In the worst case (very worst), although very remotely, it should be possible that ALL inventory items are a match for a given item movement.
Initially I wanted to retrieve all matches (in chunks, i.e. the query is "paginated") like this:
select m,i from ItemMovement m, InventoryItem i where
m.itemname=i.itemname
or m.itemCategory=i.itemCategory
or m.arbitraryQualifier=i.arbitraryQualifier
then process each movement with ALL of its matches in a very OO oriented approach, but this is taking too much time when having more than 20K of movements and 20K inventory items. I can actually SEE that the query that retrieves the data (even when paginated) takes too much time (more than a minute per page). Taking too much time is NOT the problem per se, but a constraint that forbids me to hold the transaction for more than 10 min. I know I can increase this value, but I would like to know if the approach I am taking is the right one.
I wish of course to keep a very OO approach in order to fully control the transition of the item movement and keep the arithmetic very clear. I believe the "real" question here is:
¿Is OO the right "way" to do this "kind" of process? If so, is there a design pattern which better addresses my problem in terms of performance, mantainability of the code?
¿Is this a process where I should look, for example, for a PL/SQL stored procedure instead?
I am using EJB, JPA(Hibernate). The database is Oracle.
Thanks,

Answer 1

hibernate was not designed for batch operations.
You will be able to get better performance using PL/SQL procedures than you can get with hibernate.
You must consider the entire system architecture when deciding whether to do it with java or with PL/SQL. In most cases it is possible to get sufficient performance for batch jobs with hibernate.
Regardless of what you choose, there are often ways to improve performence within the given architecture.
One very impotant thing to consider with hibernate is how you access your objects. You want to load the objects from the database using a small number of SELECT operations. Your job will most likely go quicker if you load all objects using 2 SELECT (one for each object type) than if you use 20000 (one for each movement).