• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Version Consistency EJB

 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic