Github user rafaelweingartner commented on the issue:
https://github.com/apache/cloudstack/pull/1762
@serg38 if that "AssignIpAddressFromPodVlanSearch" object was being used to
generate the SQL; should not we see a join with "pod_vlan_map" too? For me
this, this SC is very confusing.
Following the same idea of what I would do if using Spring to manage
transactions, the method "fetchNewPublicIp" does not need the "@DB" annotation
(assuming this is the annotation that opens a transaction and locks tables in
ACS). The method âfetchNewPublicIpâ is a simple "retrieve/get" method.
Whenever we have to lock the table that is being used by this method, we could
use the "fetchNewPublicIp" in a method that has the "@DB" annotation (assuming
it has transaction propagation). This is something that already seems to
happen. Methods "allocateIp" and "assignDedicateIpAddress" use
âfetchNewPublicIpâ and they have their own â@DBâ annotation.
Methods âassignPublicIpAddressFromVlansâ and
âassignPublicIpAddressâ seem not to do anything that requires a
transaction; despite misleading (at least for me) with names indicating that
something will be assigned to someone, they just call and return the response
of âfetchNewPublicIpâ method. Therefore, I do not think they require a
locking transaction.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
