RE: [jbosscache-dev] Problems with node locking semantics inJBC1.4.1.GA
by Galder Zamarreno
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
18 years, 10 months
RE: [jbosscache-dev] Documentation feedback
by Vladimir Blagojevic
Ok, enough about facking!!!
> -----Original Message-----
> From: Brian Stansberry
> Sent: Monday, January 29, 2007 4:18 PM
> To: Kabir Khan; Vladimir Blagojevic; jbosscache-dev(a)lists.jboss.org
> Subject: RE: [jbosscache-dev] Documentation feedback
>
> http://alt-usage-english.org/intro_d.shtml says it's
> indeterminate due to differing pronunciation (some people say
> "fack"). I think "an FAQ" sounds better. :-)
>
> jbosscache-dev-bounces(a)lists.jboss.org wrote:
> > I actually think it is an FAQ, since it is pronounced "an
> > Eef-Ay-Queue" :-)
> >
> >> -----Original Message-----
> >> From: jbosscache-dev-bounces(a)lists.jboss.org
> >> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf
> Of Vladimir
> >> Blagojevic Sent: 29 January 2007 20:21
> >> To: jbosscache-dev(a)lists.jboss.org
> >> Subject: [jbosscache-dev] Documentation feedback
> >>
> >> 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/f
> >> reezone/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, 10 months
RE: [jbosscache-dev] Documentation feedback
by Brian Stansberry
http://alt-usage-english.org/intro_d.shtml says it's indeterminate due
to differing pronunciation (some people say "fack"). I think "an FAQ"
sounds better. :-)
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> I actually think it is an FAQ, since it is pronounced "an
> Eef-Ay-Queue" :-)
>
>> -----Original Message-----
>> From: jbosscache-dev-bounces(a)lists.jboss.org
>> [mailto:jbosscache-dev-bounces@lists.jboss.org] On Behalf Of
>> Vladimir Blagojevic Sent: 29 January 2007 20:21
>> To: jbosscache-dev(a)lists.jboss.org
>> Subject: [jbosscache-dev] Documentation feedback
>>
>> 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/f
>> reezone/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, 10 months
FW: [jbosscache-dev] Problems with node locking semantics in JBC1.4.1.GA
by Brian Stansberry
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
18 years, 10 months
RE: [jbosscache-dev] comments on 2.0 BETA1 documentation
by Brian Stansberry
The example at the start of the User API section should use a config file rather than the default. Not really any harder to understand than what's there, and since the Configuration section refers back to it as how to do it, the more typical example is good.
jbosscache-dev-bounces(a)lists.jboss.org wrote:
> Thanks - will look into it. :-)
>
> Keep the feedback coming in, ppl!
>
>> Hi,
>>
>> Over the weekend, I read the documentation for 2.0 BETA1 taken from
>> http://tinyurl.com/36q634. Here are my comments:
>>
>> Preface
>> - 2nd paragraph, "when" should start with capital letter.
>> - "information around this" might sound better "information about
>> this"
>> - "use the JBoss Cache as a clustering", I would remove "the"
>> - 3rd paragraph, "it's" should "its"
>>
>> 1.1.
>> - "JBoss Cache... from JBoss Cache", it sounds like a repetition.
>> - "is" repeated
>>
>> 1.2
>> - Lists lines don't have dots at the end of line, they do in previous
>> section; consistency preferred.
>> - "A The Cache is organised as a tree..."; remove The
>> - "propagate any changes to all other replicated trees". Maybe you
>> wanna make a brief intro to buddy replication?
>> - Last paragraph, last sentence, "will be discussed" seems out of
>> place, "more on this later" sounds better to me.
>>
>> 1.3.
>> - Only some of the dependencies noted. Either list all or say that
>> these are some of them.
>>
>> 2.2
>> - 1st paragraph, 2nd line, "is" repeated.
>>
>> 2.4
>> - A code example using Option might be useful?
>>
>> 3.5
>> - Mention c3p0 in JDBCCacheLoader within the list of shipped
>> implementations
>>
>> 4.1.
>> - Comma missing after "CacheFactory and,"
>>
>> 4.2.
>> - "is run" should be "runs"
>> - Second paragraph, it might be better to refer to server's lib
>> directory rather than /lib dir in case people confuse it with root /
>> lib
>>
>> 4.3.
>> - It might be worth noting binding to JNDI allows the cache to be
>> accessed remotely via the invoker specified.
>>
>> 4.5.3
>> - It might help adding imports to second code example
>>
>> 4.5.4
>> - Second paragraph, addition spelled incorrectly
>>
>> 6.1
>> - Last paragraph, should be "Any modifications"
>>
>> 6.4.3
>> - It's SingletonStoreCacheLoader not, SingletonCacheLoader
>>
>> 6.5.3
>> - Disabling jboss serialization is done with "-
>> Dserialization.jboss=false". All JBoss properties follow the
>> "jboss.x" notation, should we follow similar for this as well?
>>
>> 7.1.2
>> - Same as in 1.2, this section will mention buddy replication so you
>> might wanna reword starting sentence?
>> - Is it worth mentioning when is replication queue recommended
>> using? I.e. REPL_ASYNC without TXs?
>> - 3rd paragraph, "applie at all nodes", sounds better "applied to
>> all nodes"
>> - 3rd paragraph, "this is not be the case", is this correct? "this
>> might not be the case" sounds better to me.
>>
>> 7.1.2.2.3
>> - "My default" should be "By default"
>>
>> 7.3.1
>> - We need consistency on how configuration parameters are written,
>> whether monospaced or not and whether to start them with capital
>> letters or not. See last line in first basic type and 2nd paragraph
>> in 2nd basic type. - In state transfer types, CacheLoaderPreload is
>> the old fashion way to define preloading. * There's a few of these
>> in the CacheLoader section too.
>>
>> 7.3.2.
>> - "2." section, "Here" should be "Here," ?
>> - "3." Section, 3rd line, "it's" should be "its"
>>
>> 8.1.
>> - "For example, here a database CacheLoader" does not sound alright,
>> maybe punctuation change?
>>
>> 8.2.
>> - 2nd paragraph, is the "Note that," located in the right place, the
>> paragraph is talking about CacheLoader class
>>
>> 8.2.
>> - <shared> is not explained here, maybe it's worth noting that it's
>> explained later in the Strategies section?
>>
>> 8.3.
>> - It might be worth mentioning the package where these
>> implementations are located. All of them are under o.j.c.loader
>> except Bdje and Jdbm. - I have just realised that it's only
>> JDBCCacheLoader that is currently using VAM instead of
>> serialization. Bdje and Jdbm do their own way, but FCL is still
>> using normal serialization. I guess we want FCL to use VAM as well,
>> correct?
>>
>> 8.3.1.
>> - "adding check.character.portability" is supposed to be added to the
>> properties element. This should be noted.
>>
>> 8.3.4
>> - Paragraph before last, first line, should be "instances"
>>
>> 8.5.4
>> - "When used with a transactionm anager" should be corrected
>>
>> 9.1.1
>> - policyClass explanation should start with "this is required" and
>> "one os not defined" should be corrected.
>>
>> 10.1.
>> - first line, should be "its" rather than "it's"
>>
>> 10.1.1.
>> - Maybe we should mention how we acquired WL locks when inserting/
>> removing children?
>>
>> 10.1.3.1
>> - should be "its workspace" rather than "it's workspace"
>>
>> 10.1.3.2
>> - "representation" rather than "reporesentation"
>>
>> 10.2.
>> - Shall we mention that GenericTMLookup will fallback in DummyTM if
>> it found none?
>>
>> 11.2
>> - Same as we recommended InitialStateRetrievalTimeout should be
>> longer than LockAcquisitionTimeout, we should say the same for
>> SyncReplTimeout. - UserInterceptorMBeans: mbeans in lower case, we
>> should be consistent and write it the same way in the document, as
>> MBean(s)
>>
>> 12.2.
>> - Change CacheListener events to be the same as the enums defined in
>> CacheListenerEvent.ListenerMethod, shouldn't it?
>>
>> Cheers,
>>
>> Galder Zamarreño
>> Sr. Software Maintenance Engineer
>> JBoss, a division of Red Hat
>>
>>
>>
>> _______________________________________________
>> 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, 10 months
comments on 2.0 BETA1 documentation
by Galder Zamarreno
Hi,
Over the weekend, I read the documentation for 2.0 BETA1 taken from http://tinyurl.com/36q634. Here are my comments:
Preface
- 2nd paragraph, "when" should start with capital letter.
- "information around this" might sound better "information about this"
- "use the JBoss Cache as a clustering", I would remove "the"
- 3rd paragraph, "it's" should "its"
1.1.
- "JBoss Cache... from JBoss Cache", it sounds like a repetition.
- "is" repeated
1.2
- Lists lines don't have dots at the end of line, they do in previous section; consistency preferred.
- "A The Cache is organised as a tree..."; remove The
- "propagate any changes to all other replicated trees". Maybe you wanna make a brief intro to buddy replication?
- Last paragraph, last sentence, "will be discussed" seems out of place, "more on this later" sounds better to me.
1.3.
- Only some of the dependencies noted. Either list all or say that these are some of them.
2.2
- 1st paragraph, 2nd line, "is" repeated.
2.4
- A code example using Option might be useful?
3.5
- Mention c3p0 in JDBCCacheLoader within the list of shipped implementations
4.1.
- Comma missing after "CacheFactory and,"
4.2.
- "is run" should be "runs"
- Second paragraph, it might be better to refer to server's lib directory rather than /lib dir in case people confuse it with root /lib
4.3.
- It might be worth noting binding to JNDI allows the cache to be accessed remotely via the invoker specified.
4.5.3
- It might help adding imports to second code example
4.5.4
- Second paragraph, addition spelled incorrectly
6.1
- Last paragraph, should be "Any modifications"
6.4.3
- It's SingletonStoreCacheLoader not, SingletonCacheLoader
6.5.3
- Disabling jboss serialization is done with "-Dserialization.jboss=false". All JBoss properties follow the "jboss.x" notation, should we follow similar for this as well?
7.1.2
- Same as in 1.2, this section will mention buddy replication so you might wanna reword starting sentence?
- Is it worth mentioning when is replication queue recommended using? I.e. REPL_ASYNC without TXs?
- 3rd paragraph, "applie at all nodes", sounds better "applied to all nodes"
- 3rd paragraph, "this is not be the case", is this correct? "this might not be the case" sounds better to me.
7.1.2.2.3
- "My default" should be "By default"
7.3.1
- We need consistency on how configuration parameters are written, whether monospaced or not and whether to start them with capital letters or not. See last line in first basic type and 2nd paragraph in 2nd basic type.
- In state transfer types, CacheLoaderPreload is the old fashion way to define preloading.
* There's a few of these in the CacheLoader section too.
7.3.2.
- "2." section, "Here" should be "Here," ?
- "3." Section, 3rd line, "it's" should be "its"
8.1.
- "For example, here a database CacheLoader" does not sound alright, maybe punctuation change?
8.2.
- 2nd paragraph, is the "Note that," located in the right place, the paragraph is talking about CacheLoader class
8.2.
- <shared> is not explained here, maybe it's worth noting that it's explained later in the Strategies section?
8.3.
- It might be worth mentioning the package where these implementations are located. All of them are under o.j.c.loader except Bdje and Jdbm.
- I have just realised that it's only JDBCCacheLoader that is currently using VAM instead of serialization. Bdje and Jdbm do their own way, but FCL is still using normal serialization. I guess we want FCL to use VAM as well, correct?
8.3.1.
- "adding check.character.portability" is supposed to be added to the properties element. This should be noted.
8.3.4
- Paragraph before last, first line, should be "instances"
8.5.4
- "When used with a transactionm anager" should be corrected
9.1.1
- policyClass explanation should start with "this is required" and "one os not defined" should be corrected.
10.1.
- first line, should be "its" rather than "it's"
10.1.1.
- Maybe we should mention how we acquired WL locks when inserting/removing children?
10.1.3.1
- should be "its workspace" rather than "it's workspace"
10.1.3.2
- "representation" rather than "reporesentation"
10.2.
- Shall we mention that GenericTMLookup will fallback in DummyTM if it found none?
11.2
- Same as we recommended InitialStateRetrievalTimeout should be longer than LockAcquisitionTimeout, we should say the same for SyncReplTimeout.
- UserInterceptorMBeans: mbeans in lower case, we should be consistent and write it the same way in the document, as MBean(s)
12.2.
- Change CacheListener events to be the same as the enums defined in CacheListenerEvent.ListenerMethod, shouldn't it?
Cheers,
Galder Zamarreño
Sr. Software Maintenance Engineer
JBoss, a division of Red Hat
18 years, 10 months
JDBCCacheLoader performance
by Mircea Markus
Hi guys,
I've drafted the alternative implementation of JDBC cache loader. Just a
brief, the base idea is to to traverse the tree in preorder and add some
indexing info to each node.
The affected methods are remove(Fqn), loadState(Fqn subtree, ..) and
put(Fqn, value).
How I've tested the performance:
a tree with a TREE_DEPTH depth is created. Each node in the tree has a
CHILDREN number of children. By default I've used TREE_DEPTH=7 and
CHILDREN=3 which gave a total number of 3280 children. A node is selected at
each depth from disjunct subtrees. ( i.e. in the benchmark used 7 nodes
are selected). On all those nodes a certain operation is performed:
loadState or remove. For benchmarking the put operation, the in memory tree
nodes are Collections.shuffle(List<Fqn>), then they are (randomly) added to
the database/classLoader.put. Also additional testing was performed in the
case of put for deep trees (100 - 200 nodes)
Results:
On the load and delete the new implementation is much more better. The
new deletion time is linear compared with the old approach where recursive
db calls lead to an exponential raise(see - remove_node_all.PNG). Relatively
the same in the case of loading subtrees(see - remove_node_all.PNG).
The problem is in the case of additions. When adding all 3280 nodes the time
is constantly 10 times bigger than when using existing implementation.
Profiling shewed that the update_indexes operation behaves really badly -
nothing to do in this area. Even if the operation is totally moved in the
database (mysql 5.0.X has limitations on working with triggers so I've used
a stored procedure) is doesn't cause an significant increase.
Another approach.
Another approach I've consider is to reduce the recursive DB calls to a fix
number. All operation rely on the fact that the entire fqn is persisted for
each node. E.g. when deleting node(/a/b/c) I'll remove all records that
have a path starting with (/a/b/c/). Same in the case of node loading. It
proved to work even better than in the case of first implementation.
Recursion in the case of insertions - I've solved this by
a) querying for the first persited ancestor
b) add all the children in a batch pr statement.
Interestingly enough this always-2-queries approach is 30% slower than the
old recursive impl. Profiling showed that the db driver (mysql-connector/J)
takes the same time for executing a batch (new impl) as it takes in the case
of individual calls (old impl).Also the firstAncestor query takes quite long
on mysql. Another observation is that new impl proves much better in the
case of deeper trees, and fails up-2 50% in the case of flatter trees. An
interesting thing would be to see it working on an Oracle/SqlServ... The
good news is that old implementation can be used instead - or a policy can
be defined to use the new impl where tree structure requires it.
Naturally I'd chose the second approach - if you don't see any problem with
it
I'll stop here :)
Cheers,
Mircea
18 years, 10 months
