aspose file tools*
The moose likes EJB and other Java EE Technologies and the fly likes Version Consistency EJB Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Version Consistency EJB" Watch "Version Consistency EJB" New topic
Author

Version Consistency EJB

Safin Ahmed
Greenhorn

Joined: Feb 08, 2006
Posts: 19
Hi,

i've been reading about Version Consistency in EJB
And i'm having difficulties understanding something

The ejbStore() method validates the correct version in the Bean in the dataase, and update call adds 1 to the row when it enters the database (by the means of a trigger).
So far so good.

How does this information get mapped again in the EJB ? How does the bean get the new version value ?
Do we have to find the bean again as a new bean?

Because i read that
"...except that the ejbLoad() method loads its initial data (including the version number) from an internal cache."

Meaning that we will load always the same bean if we don't create a new one.
And if we save it once, we will never be able to save it again, because we will have a incorrect version number

Can someone explain this to me ?

Thanks
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
You are reading the Sun One docs, yes? I haven't used their implementation, but have used something similar, and mucked around with timestamp-based optimistic locks. So far my reaction is:

Run away. Far away. Save your life while you can.

This stuff can get confusing, and I haven't had much luck getting performance differences in a real app that warranted the complication. There might be highly-loaded transactional systems that need this but I haven't hit a situation yet that wasn't better served by first figuring out if there wasn't something more fundamentally wrong with how processing was being performed.

One big caveat to that is I haven't pounded hugely on clustered situations, and I can imagine that could change the situation.

To answer your original question more concretely, muck around with options for logging the actual SQL activity in the CMP layer. I think you'll undertand much more clearly what is going on at that point. Even doing that without version consistency would be informative. Containers do a lot more probing into the database than you might expect, and the Sun One explanations will make more sense to you after you've seen those probes. Also, if you experiment with vendor-specific options for tuning how the CMP layer works and see the consequent alterations in that probing, you'll also get a better sense of why you'll often not care about version consistency as a potential solution. I think you'll find that you end up trading row locks for read probes, so I think you'll only win with VC if lock contention truly has become your bottleneck.
[ February 15, 2006: Message edited by: Reid M. Pinchback ]

Reid - SCJP2 (April 2002)
 
Don't get me started about those stupid light bulbs.
 
subject: Version Consistency EJB