On Jan 18, 2007, at 3:15 PM, Murray Altheim wrote:
Igor Minar wrote:
I haven't looked at v2.2 JDBCProvider, nor have I thoroughly
studied all the JSPWiki source code, but unless there are some
major complications due to some internal caching within the
WikiEngine, I'd use similar strategy for data consistency
management(versioning) as Hibernate or ActiveRecord (from RoR) are
using.
That means to have one int field per each record in the table that
is set to 0 by default and increments with every change to that
record. To successfully update a record the version number must be
unchanged since your last read, otherwise you are updating newer
version of the record than the one you made modifications to.
This is pretty basic strategy that can be used even in clustered
environment (things can get complicated a bit if caching is used
as well). This could solve the problem you saw, what do you think?
cheers,
Igor
Hi Igor,
Hi :)
Well, I can't speak to any expertise with exactly what JSPWiki does
with its caching, but it certainly has a cache. If someone were
using a DB backend it might be necessary to turn off JSPWiki's
cache to keep things synchronized across multiple engines since the
caching function would mess with that.
All the Hibernate-like versioning was just a though I got when
reading your post. I'm pretty happy with file providers, but I can
imagine that if someone wanted to build a HA wiki site then multiple
WikiEngines connected to a single data storage is a must (correct me
if I'm wrong).
Regarding the caching issues: cache data for all View-s (expire cache
every X minutes) and bypass cache for rendering Edit views. That
should solve most of the problems.
Just a couple of ideas :)
cheers,
i
_______________________________________________
Jspwiki-users mailing list
[email protected]
http://ecyrd.com/cgi-bin/mailman/listinfo/jspwiki-users
