RE: [jbosscache-dev] Problems with node locking semanticsinJBC1.4.1.GA
by Galder Zamarreno
But thinking through it again, not any riskier than the isolation level set in the config.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Galder Zamarreno
Sent: 30 January 2007 01:07
To: Brian Stansberry; jbosscache-dev(a)lists.jboss.org
Cc: Max Andersen; Steve Ebersole; Bill Decoste; Carlo de Wolf
Subject: RE: [jbosscache-dev] Problems with node locking semanticsinJBC1.4.1.GA
Actually, I had a case this morning asking about this. The customer wanted to could control what the locking type to acquire. I did comment against it due to possible misuse that could end up in data corruption.
I can see however the possible use cases, but the risks are high as well IMO.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Brian Stansberry
Sent: 29 January 2007 21:49
To: jbosscache-dev(a)lists.jboss.org
Cc: Max Andersen; Carlo de Wolf; Bill Decoste; Steve Ebersole
Subject: FW: [jbosscache-dev] Problems with node locking semantics inJBC1.4.1.GA
Accidentally didn't include the rest of the distribution on this
response.
Brian Stansberry wrote:
> I like your thinking on that. Haven't looked at the details, but the
> concept makes a lot of sense.
>
> Was chatting with Manik on this this AM, and here's what we came up
> with as an action plan. This is somewhat governed by very tight
> release schedules for 1.4.x, along with a desire to not change the
> Node interfaces in the 1.x series.
>
> For both Branch_1_4_0 and HEAD:
>
> 1) I'll add cache configuration attribute
> LockParentForChildInsertRemove. 2) I'll change PLI to use that to
> decide whether to acquire a WL or RL. 3) Manik will look into
> changing optimistic locking uses that to decide whether
> addition/removal of a child causes an increase in the nodes version.
> (Not sure if that will be in 1.4.x).
>
> For HEAD only:
>
> 4) I'll add a JIRA to make this behavior changeable per node. I'll
> open a forum thread for the JIRA and without objection, Elias, I'll
> paste your idea as the first post.
>
> - Brian
>
> Elias Ross wrote:
>> --- Brian Stansberry <brian.stansberry(a)jboss.com> wrote:
>>
>>> Even further, that could be treated as a cache wide default, used to
>>> set a flag on each node. The PessimisticLockInterceptor could check
>>> that flag to decide whether to get the WL. What's nice about that
>>> is the cache wide default could be true, but for certain nodes the
>>> application could set it to false. E.g the root node for a webapp
>>> under which sessions are stored, root node for an SFSB or entity
>>> under which instances are stored, PojoCache's _JBossInternal_ node
>>> etc. Simpler alternative to lock striping on the child map.
>>
>> The Node itself keeps a NodeLock instance. Perhaps the specific
>> choice of lock (read-write) could be delegated to the NodeLock
>> itself?
>>
>> In particular, for the method:
>>
>> boolean acquire(Object caller, long timeout, NodeLock.LockType
>> lock_type);
>>
>> it might make sense to replace the LockType parameter with an
>> operation parameter? E.g.
>>
>> boolean acquire(Object caller, long timeout, NodeLock.Operation op);
>>
>> Then there needs to be some way to set the particular strategy per
>> node. It's theoretically possible, but there needs to be a standard
>> API to expose this. E.g.
>>
>> void setLockStrategy( ... );
>>
>> With this in mind, the NodeLock interface should get revisited in
>> time for 2.0.
>>
>>
>>
>> ______________________________________________________________
>> ______________________ Get your own web address.
>> Have a HUGE year through Yahoo! Small Business.
>> http://smallbusiness.yahoo.com/domains/?p=BESTDEAL
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 11 months
RE: [jbosscache-dev] Building docs
by Galder Zamarreno
The new documentation is under docs/JBossCache-UserGuide, you need to make the changes there otherwise, they won't show up. The main build calls here.
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
-----Original Message-----
From: jbosscache-dev-bounces(a)lists.jboss.org [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of Vladimir Blagojevic
Sent: 30 January 2007 07:43
To: Brian Stansberry
Cc: jbosscache-dev(a)lists.jboss.org
Subject: RE: [jbosscache-dev] Building docs
Same thing happened to me. I was not curious enough to invesigate why it
happens since I figured out that I can build separate parts of doco by
going in respective directories directly and invoke a build there.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Brian Stansberry
> Sent: Monday, January 29, 2007 9:46 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Building docs
>
> How do you build the docs in HEAD now? I added a paragraph for
> JBCACHE-955 and want to see what it looks like, but when I
> run build docs it seems to do a lot of stuff without failing,
> but at the end of the process the only thing I can find is
> the PojoCache FAQ.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
_______________________________________________
jbosscache-dev mailing list
jbosscache-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-dev
18 years, 11 months
RE: [jbosscache-dev] Building docs
by Vladimir Blagojevic
Same thing happened to me. I was not curious enough to invesigate why it
happens since I figured out that I can build separate parts of doco by
going in respective directories directly and invoke a build there.
> -----Original Message-----
> From: jbosscache-dev-bounces(a)lists.jboss.org
> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
> Brian Stansberry
> Sent: Monday, January 29, 2007 9:46 PM
> To: jbosscache-dev(a)lists.jboss.org
> Subject: [jbosscache-dev] Building docs
>
> How do you build the docs in HEAD now? I added a paragraph for
> JBCACHE-955 and want to see what it looks like, but when I
> run build docs it seems to do a lot of stuff without failing,
> but at the end of the process the only thing I can find is
> the PojoCache FAQ.
>
> Brian Stansberry
> Lead, AS Clustering
> JBoss, a division of Red Hat
> Ph: 510-396-3864
> skype: bstansberry
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
18 years, 11 months
Building docs
by Brian Stansberry
How do you build the docs in HEAD now? I added a paragraph for
JBCACHE-955 and want to see what it looks like, but when I run build
docs it seems to do a lot of stuff without failing, but at the end of
the process the only thing I can find is the PojoCache FAQ.
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
Ph: 510-396-3864
skype: bstansberry
18 years, 11 months
Documentation feedback
by Vladimir Blagojevic
Here is my feedback. Cheers.
Preface:
Rather than "Along with it's accompanying" it should be "Along with its
accompanying".
"an FAQ". Even I know that this is a wrong preposition!
"When used." Use capital.
"A tree-structured, clustered". Missing comma.
Chapter 1:
1.1
"JBoss Cache is a tree-structured, clustered, transactional cache from
JBoss Cache." This sentence is confusing.
1.1.1
"maintaining object references even affter replication or persistence".
Too many rrrss.
"More on concurrency, locking and isolation levels will be discussed
later". I would rather say
"Concurrency, locking and isolation levels will be discussed later".
1.2
"A The cache is organised as a tree, with a single root." Obvious
preposition problem.
In this section writer goes on to describe what "we" do in such and such
case. Maybe this can be rewritten
not to say what we do but rather what Jboss cache does. Just a matter of
style. For example: "When a change
is made to an object in the cache and that change is done in the context
of a transaction, then we defer the
replication of changes until the transaction commits successfully"
becomes "When a change is made to an object
in the cache and that change is done in the context of a transaction,
replication of changes is deferred until
the transaction commits successfully."
2.2
"and an instance is is created"
3.1
I would put introduction parameter *before* API image.
3.4
I would put introduction parameter *before* API image. Should we explain
a bit more what pre boolean parameter
is about as well as isLocal parameter.
3.5
Instead of term "CacheLoader(s)" use "cache loader(s)" when not
referring to a specific cache loader?
Mention not to use FileCacheLoader in production :)
4.2
When we already mention that jboss cache is deployed as jboss-cache.jar
rather than the service archive
the question immediately pops up - why?
5.0
Link to compatibility page?
6.1
"How your data is organised" ?? Ugh. Maybe something else...
6.3
How Calls Are Invoked On The Data Structure -> "Node invocations"
6.3.3
"This context is one that holds intermediate state for the duration..."
-> "IvocationContext holds intermediate state for the duration..."
I would rewrite this section like this:
InvocationContext holds intermediate state for the duration of a single
cache method invocation, and is
set up and destroyed by the InvocationContextInterceptor which sits at
the start of the chain.
InvocationContext, as its name implies, holds contextual information
associated with a single cache method
invocation. Contextual information includes associated
javax.transaction.Transaction or
org.jboss.cache.transaction.GlobalTransaction, method invocation node
origin (InvocationContext.isOriginLocal())
as well as Option overrides (link ref).
InvocationContext can be obtained .blah blah blah...
7.1.2.1
"single modification os broadcast rather" -> "single modification is
broadcast rather"
8.1
loadEntireState and storeEntireState are outdated. They refer to the old
implementation.
I would replace these with some description similar to current javadocs.
http://labs.jboss.com/file-access/default/members/jbosscache/freezone/do
cs/2.0.0/api/org/jboss/cache/loader/CacheLoader.html
8.2
Shared is not explained in the same bullet point list as other elements
of configuration.
8.5 Strategies
Strategies of what? This section needs an introduction!
I would also add a use case for using several cacheloaders in a chain.
To be honest I never really
understood the advantage of it. Increased fault tolerance?
8.5.4 "Replicated Caches With Each Cache Having It's Own Store" ->
"Replicated Caches With Each Cache Having Its Own Store"
"When used with a transactionm anager". Typo.
What is the advantage of each cacheloader having its own store? This
should be explained.
8.5 Should explain tradeoffs of various strategies!
This is a very interesting JBC feature and a topic in general to be left
in such non elaborated state.
9.1.2
"eventQueueSize - this optional parameter defines how large a queue of
items to evict to create". Huh???
policyClass explanation has several typos.
9.2.1 timeToLiveSeconds . I do not understand this parameter. Does it
mean that the node is swept away
only if it has not be accessed in certain period of time? Idle is not
defined.
10.1.2.1
Isolation level explanation is a bit fuzzy. I like how isolation levels
are explained in clustering course material
but I am not sure if we should include it here.
10.1.3.2
"it makes sense to aling the versions". Align spelling problem.
"in-memory reporesentation". Spelling.
11.2
Mention that ReplQueueInterval and ReplQueueMaxElements values are
considered only if UseReplQueue is true.
Mention that SyncReplTimeout should be bigger than
LockAcquisitionTimeout.
18 years, 11 months
