Hmm. You potentially have a good point about the transaction retries, I
hadn't considered that. I wouldn't have expected the application server to
retry with an application-level exception is thrown, though. Do you know
that to be the case?
I like to keep the validation within the OM for a stronger OOP design,
wherein the objects cannot be loaded with invalid data. That said, I've had
to make a number of tradeoffs for EJB already, this may be another. I've
seen a number of postings where people put snapshots in the value objects,
but when you get to that point, EJB just seems as if you're using it for a
really clumsy persistence layer instead of true enterprise objects.
Our validation helper classes are already re-usable, so I wouldn't gain much
there. We also have a CompositeValidationException class with a map of
validation errors--interesting to see you went with a similar approach.
- Geoffrey
: -Original Message-
: From: Manuel De Jesus [mailto:[EMAIL PROTECTED]]
: Sent: Tuesday, January 29, 2002 2:11 AM
: To: Orion-Interest
: Subject: RE: TX Was Null
:
:
: I don't think that relying on your Entity Beans for front line data
: validation is a good design. As a rule of thumb to get the
: best performance
: in applications you want to validate as early as you can to
: save the trouble
: of having to process all the steps for a transaction only to
: find the data
: is invalid when you want to save things and use this to throw
: an error. In
: most app servers you usaully set transaction retries to at
: least 2 (incase
: there was a network/temporary error on the first attempt this
: increases the
: reliablity) - by throwing data validation exceptions at the
: EJB level you
: are looking at doing a TX twice before reporting the error
: ... terrible
: performance.
:
: What I have done in projects is to abstract validation to a set of
: Validation classes that are normal java classes which can
: be used on the
: jsp/ejb etc etc tier. These classes interact with the
: database via singleton
: caches allowing for dynamic validation updates (worth their
: weight in gold).
: This also means that the stand alone validation objects can
: be easily reused
: in other projects, expecially the rules that are generic enough :).
:
: Using a separate set of validation classes I would suggest:
: 1) Validate the TX at the point where it starts right up
: front if you are
: using jsp etc if this is an option.
: 2) Validate the TX in the actual session bean. We use a
: custom exception
: with a Vector of string mappings that allows us to complain
: about more than
: one error etc.
: 3) If you are really paranoid/have mutiple update points you can also
: validate at the entity bean and even a littel at the db level
: (not null,
: size etc).
:
: Since you are using a shared validation library, changing the
: validation is
: done in one place. In addition your application = 100 times
: faster since you
: are not rolling back transactions a million times over. And
: the big bonus is
: it will work on 99% of app servers.
:
: Regards,
: Manuel
:
:
: -Original Message-
: From: [EMAIL PROTECTED]
: [mailto:[EMAIL PROTECTED]]On Behalf Of
: [EMAIL PROTECTED]
: Sent: Monday, January 28, 2002 5:13 PM
: To: Orion-Interest
: Cc: [EMAIL PROTECTED]
: Subject: TX Was Null
:
:
: We're coming up on our deployment date, so we're considering
: our deployment
: options (notably, at this point, JBoss and Orion).
:
: The system is running and working under JBoss, and I've been
: re-porting it
: to Orion so that we can do some testing, try and resolve some
: issues we had
: under Orion (for which we got some help from Atlassian that
: we haven't had a
: chance to try out yet). In the process, we've re-adjusted
: most or all of
: the finders, and fixed a few bugs here and there between what
: JBoss does and
: what Orion does. It's been enlightening, as usual.
:
: That said, we've run up against a brick wall. One of our
: transactional
: saves uses a session bean to save two entities in a combined
: declarative
: transaction. Each of these beans can throw validation exceptions when
: passed data that's meant to save. We have two unit tests,
: one which throws
: invalid data into the first object, and another which throws
: invalid data
: into the second object.
:
: The second object is relatively easy -- if it has problems,
: the session bean
: sets the transaction to rollback only, and lets the server do
: the rest of
: the work. This works under both Orion and JBoss as expected.
:
: If the first object fails, though, there are larger issues --
: we still want
: to find out if there's a problem with the data being passed
: to the second
: object. Under JBoss, if we tried to do this in the same
: transaction, it
: complained that the transaction was already rolled back,
: which is sensible.
: So we put the validation method into a 'requires new' transaction