Business Components Without the Business: Part III

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

Business Components Without the Business: Part II

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

Business Components Without the Business: Part I

Last week I talked about where business logic should go in an enterprise application, and voiced my firm opinion that sometimes–but not always–it belongs in the database. But if you’re using Oracle ADF, there’s a tricky point about this: ADF does not handle trigger-raised database errors especially well, so has no out-of-the-box way of nicely integrating with database validation. Even if you’re not using ADF (and, in particular, ADF BC), knowing what sort of thing is involved in getting database error messages into a user-friendly form may prove useful.

Continue reading Business Components Without the Business: Part I

The Business Logic Wars

In an enterprise application, there are lots of choices about where to put business logic–validation rules, value calculation, and so on. You can put it in the database, in the server-side web application (and there, you have a decision about whether to put the code in the model or the controller), or as Javascript running on the client. Where should you choose to put your application’s business logic?

That’s a great question to ask in a bar full of developers of mixed backgrounds, if you like bar fights. SQL programmers will say you should put your business logic in database triggers, where it’s most secure and robust. Heavy-duty Javascript types will say that, at the least, business logic needs to be redundantly implemented in Javascript, to improve client interaction and reduce server round trips. And people from the Java EE community will tell you that the database is for data and that RIAs give you performance almost as good as Javascript without the security concerns, and that you should take the compromise (and the best-structured, most extensible option) and put the business logic into the middle tier.

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

Bring Back the Hobgoblin: Dealing with RowInconsistentException

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.

Continue reading Bring Back the Hobgoblin: Dealing with RowInconsistentException