LPS-36046
LPS-36046
LPS-35981 Changing constant names for lock retry delay and lock timeout because we will use them in other services as well
LPS-35981 No need for the current value, so deprecate this method too
LPS-35981 We already have a lot of methods, and we'll add some more, so buy some space back
LPS-35981 Add some utility methods we're going to use later
LPS-35981 Remove the original increment logic, we're only going to change values not create new ones
LPS-35981 The processing logic change: first fetch or create all the counters (it can involve new transactions) - then simply loop through and increment them
LPS-35981 We're also going to create activity limits in step 1, so we just really need to check them
LPS-35981 Logic for fetching/creating counters and limits used in step 1 of the process
LPS-35981 This is the method we're calling from within a LockProtectedAction, so first check if another thread has added the limit we're trying to create
LPS-35981 With the new logic we no longer need special behaviour for HSQL
LPS-35981 Generated
LPS-35981 Minor SF
LPS-35981 Move out the constants to a local variable in SocialActivityCounterLSI unless it's used elsewhere, and then we would have to namespace the constants. Right now, in SocialActivityCounterDefinition, you have LIMIT_*, which makes it obvious what they are. Perhaps the naming is good enough… we'll revisit if we have to.
LPS-35981 Ran "ant format-javadoc -Dlimit=SocialActivityCounterLocalServiceImpl"
LPS-35981 Rename methods so that we don't get the "public deprecated" createActivityCounter confused with the "protected" createActivityCounter. This is like the popular safePut pattern, but lockProtectedVerb.
LPS-35981 Sort, no logic changes
LPS-35981 This method doesn't actually add an activity counter, but determines if we should add one or not. So the name is misleading.
LPS-35981 But these methods really do add an activity counter, especially since the method that starts the call stack for these methods is called addActivityCounters