> What is the correct resolutions ?
The correct resolutions is to hire a J2EE Architect to tackle this issue. You really need someone with software development experience to understand the problems of your current application.
You might not have the expertise to hire a real J2EE Architect, so I suggest that you first find a good agency to help you find a real J2EE Architect. Make sure that you pick a good agency cause you might end up with a 4-month special and waste a lot of money.
One of my last major J2EE projects failed because the J2EE Architect did not possess any real J2EE-skills. He did know how to create JSP pages and helped out with requirements gathering.
He was fooling the senior management for a good year and a half before his lack of real experience was exposed. He only had a rudimentary understanding of J2EE APIs and sapped the organization for a $130K salary. His main strategy was to complain about everything and be very argumentative with the Sun and IBM consultants.
He convienently resigned two weeks beofre our project was due.
Thanks. It seems like I need to inform my colleages that this 200,000-update process is a business logic problem.
But what if this is a real life needed process ? We already have a good team of architects and developers.
The EJB container allows flexibility to set boundaries of transaction but this may require us to break down the process.
Is re-designing business logic a better solution ? It is better to consider some opinion from this forum.
Thanks.
ET.
> It seems like I need to inform my colleages
> that this 200,000-update process is a business logic
> problem.
This might help a great bit.
>
> But what if this is a real life needed process ? We
> already have a good team of architects and
> developers.
This statement is questionable. There is a fundamental problem with "one transaction that has more than 200,000 update processes".
Aside, which also indicates the skill level of this "good team of architects and developers", if it really exists.
Your group should rethink what is considered a transaction and really analyze the reasons why so many updates need to occur as one batch.
It would be fantastical if this system could maintain 200,000 live Entity EJB at any one point in time. Either way, you need to rethink, from business terms, what a transaction should be.
This sounds like a data bulk upload process. There may be no business analysts involved to guide you. You should refer to the "good team" for their advice in addition to this forum. They should be able to provide you with good direction.