Enhance service semaphore to support parameter-based locking

[dixitdeepak]

Enhance service semaphore to support parameter-based locking (OFBIZ-13395)

• Added semaphore-parameter-name attribute to service definitions
• Extended ServiceSemaphore to include parameterValue
• Updated locking logic to use (serviceName, parameterValue) scope
• Modified dispatcher to pass parameter values from service requests
• Allows concurrent execution of the same service for different parameter values
• Enables finer-grained concurrency control compared to service-level locking

Please use the following SQL to update the service_semaphore table schema for parameter-based locking support:

ALTER TABLE service_semaphore DROP PRIMARY KEY;

ALTER TABLE service_semaphore
ADD PRIMARY KEY (service_name, parameter_value);

[jacopoc]

@dixitdeepak , your implementation looks correct and straightforward. Although I haven’t tested it, it should work without causing regressions.

That said, while I can see it being useful for specific use cases (for example, when locking based on the value of a single parameter), I have some doubts about whether it is a good fit for more general scenarios.

A few more specific remarks:

• Specifying the parameter name through the semaphore-parameter-name attribute may introduce inconsistencies (for example, the provided name may not match any valid service parameter). Also, it should not be possible to specify an optional parameter.
• Restricting this to a single parameter feels somewhat arbitrary and does not seem well suited to more general use cases.

For these reasons, instead of semaphore-parameter-name, I think it would be better to add an attribute on the service parameter element itself to indicate whether that parameter should be included in the lock.

Regarding the data model, I am not sure it is worth the added complexity of introducing a separate entity to store multiple attribute values flexibly. That approach could also make the locking process trickier, less robust, and less efficient. One possible alternative would be to hash all relevant parameter values, append the result to the service name, and keep the existing single-field primary key.

In its current form, I still think your patch could be useful for others with similar use cases. However, in my opinion, it may be better to keep it in a Jira ticket or pull request for reference rather than merging it directly into the codebase.

[dixitdeepak]

Thanks for the review @jacopoc

Yes, the current implementation in the PR supports locking based on a single parameter only. It would definitely be useful to extend this capability to support multiple service input parameters as part of the semaphore key.

I like the idea of supporting multi-attribute semaphores. However, I am still in favor of adding a new field to the ServiceSemaphore entity to store the parameter value(s). The value could be stored using a pattern similar to how EntityAuditLog.pkCombinedValueText stores combined PK values.

This would keep the implementation relatively straightforward while still allowing support for composite parameter-based locking.

I am moving this PR to draft for now.