Over the last two weeks, I’ve been talking about model layer code to facilitate integration of database-level validation logic into an ADF application. This week, let’s finish off the project by writing the controller-layer code that will turn these custom exceptions into nice, user-friendly error messages. Continue reading Business Components Without the Business: Part III
Last week, I talked about how to code database error messages, entity object classes, and custom exceptions to facilitate integration of database-level validation logic into an ADF application. And I promised that this week, we’d finish off the project by writing the controller-layer code that will turn these custom exceptions into nice, user-friendly error messages, right? Well, I’m not going to do that, because I actually forgot something at the ADF Business Components (ADF BC) layer. Controller stuff next week. I really promise this time.
Continue reading Business Components Without the Business: Part II
I have my own very strong opinion on where to put business logic, but it isn’t any of the above. It’s this: It depends. Continue reading The Business Logic Wars
If you scan through the posts at OTN, one exception that comes up again and again as confusing is
oracle.jbo.RowInconsistentException, aka JBO-25014. What causes this exception? Well, as we’ll see below, the answer isn’t so simple. But the proximal cause is that all of the following have occurred:
- The application uses optimistic locking
- The application has invoked a commit operation
- A particular entity object instance has been marked as changed (requiring update)
- The current values of the corresponding row in the database do not match the original values queried for the row (or, if you’re using change indicators, the current values of the change indicator fields in the database do not match the values of the corresponding attributes)
Now sometimes, you get a
RowInconsistentException because another user has actually changed and committed the row in the database since it was queried. That’s, in fact, the case that
RowInconsistentException was intended to flag–it’s to keep data integrity, so you don’t get people writing over each other willy-nilly. If you’re getting a
RowInconsistentException for this reason, then there’s no bug to fix or work around. You’ve simply run afoul of a (hopefully rare) coincidence.