Only 48 hours left in the trailboss' kickstarter!

New rewards and stretch goals. CLICK HERE!

  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Version Consistency EJB  RSS feed

Safin Ahmed
Posts: 19
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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 ?

Reid M. Pinchback
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!