Video podcast on handling inconsistencies when using WebSphere Extreme Scale

This video podcast covers the issue when an application uses cached data in WebSphere Extreme scale and then a third party application updates that data without going through Extreme Scale. It covers how the inconsistency arises and then how the application must be coded mechanically to deal with the inconsistency. It also covers whether using a database trigger with invalidation messages solves the inconsistency or not.

You can watch a streamed version here.

Download websphere_extreme_scale_weekly_podcast_medium.m4v

Comments

[John Heintz]

Thanks for publishing this.

I like the way you led from just optimistic locking alone to invalidation messages + optimistic locking when more than just a few (1-2%) collisions would occur.

Something that I've wondered about is how to keep "sets" of objects in sync. For example:
1. App1 read A from grid
2. App2 writes A and B to DB
3. App1 reads B from grid
4. App1 adds C=A+B and stores C into grid

Even with optimistic locking would this still be able to result in inconsistent data?

Thanks,
John Heintz

[bnewport]

There are two ways to do optimistic locking. The common approach is to use over qualified updates which catches records about to be updated which are stale but doesn't catch referenced un changed records who value may have been used to calculate changes. The trick here is checking the version numbers on EVERY record in the transaction, not just the ones that changed.

[John Heintz]

I see that would work, now I'm interested in how to accomplish it ;)

After a few thought experiments...
This is the kind of thing that has to be dealt with in code, intentionally, and can't be relegated to middleware, right?

Thanks, John

[Billy]

I think middleware can do it, something like a JPA knows what was read for the current transaction and can therefore check if those versions are still valid. This may be too paranoid though.