Permission service not on the same transaction

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Permission service not on the same transaction

Nicolas Malin-2
Hello,

Currently I continue the conversion on shipment  crud service and I detected that many service use the same mini-lang call to check if the shipment status is ok for editing "checkCanChangeShipmentStatusPacked"

I convert it on service to call it directly by the permission-service like that :

    <service name="createShipmentPackageContent" default-entity-name="ShipmentPackageContent" engine="entity-auto" invoke="create" auth="true">...
        <permission-service service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
        <auto-attributes include="pk" mode="IN" optional="false"/>...
    </service>

The problem with this change that when I run the unit tests, I have some failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on the same service's transaction.
I a realize this change :

Index: framework/service/src/org/ofbiz/service/ModelService.java
===================================================================
--- framework/service/src/org/ofbiz/service/ModelService.java    (révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java    (copie de travail)
@@ -985,7 +985,7 @@
                 LocalDispatcher dispatcher = dctx.getDispatcher();
                 Map<String, Object> resp;
                 try {
-                    resp = dispatcher.runSync(permission.name, ctx, 300, true);
+                    resp = dispatcher.runSync(permission.name, ctx);
                 } catch (GenericServiceException e) {
                     Debug.logError(e, module);
                     Map<String, Object> result = ServiceUtil.returnSuccess();

All unit test pass.
Anyone know the reason to call the permission service on a new transaction ?
I couldn't spot any valid reason.

Thnaks for help ;)

Nicolas

--
#jeSuisCharlie
logoNrd
Nicolas Malin
Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
[hidden email]

8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz |  ofbiz-fr |  | réseau LE
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
No remarks on this case ?

If the silent is present I open an issue and commit this patch ;)

Nicolas

Le 07/04/2016 10:00, Nicolas Malin a écrit :
Hello,

Currently I continue the conversion on shipment  crud service and I detected that many service use the same mini-lang call to check if the shipment status is ok for editing "checkCanChangeShipmentStatusPacked"

I convert it on service to call it directly by the permission-service like that :

    <service name="createShipmentPackageContent" default-entity-name="ShipmentPackageContent" engine="entity-auto" invoke="create" auth="true">...
        <permission-service service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
        <auto-attributes include="pk" mode="IN" optional="false"/>...
    </service>

The problem with this change that when I run the unit tests, I have some failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on the same service's transaction.
I a realize this change :

Index: framework/service/src/org/ofbiz/service/ModelService.java
===================================================================
--- framework/service/src/org/ofbiz/service/ModelService.java    (révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java    (copie de travail)
@@ -985,7 +985,7 @@
                 LocalDispatcher dispatcher = dctx.getDispatcher();
                 Map<String, Object> resp;
                 try {
-                    resp = dispatcher.runSync(permission.name, ctx, 300, true);
+                    resp = dispatcher.runSync(permission.name, ctx);
                 } catch (GenericServiceException e) {
                     Debug.logError(e, module);
                     Map<String, Object> result = ServiceUtil.returnSuccess();

All unit test pass.
Anyone know the reason to call the permission service on a new transaction ?
I couldn't spot any valid reason.

Thnaks for help ;)

Nicolas

--
#jeSuisCharlie
logoNrd
Nicolas Malin
Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
[hidden email]

8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz |  ofbiz-fr |  | réseau LE

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Pranay Pandey-3
In reply to this post by Nicolas Malin-2
Hi Nicolas,

Calling it as permission service is tricky. I see the comment in implementation above the simple method in ShipmentServices.xml-

    <!-- Check the Status of a Shipment to see if it can be changed - meant to be called in-line -->

It was implemented with a purpose to be called inline, may be supporting the traditional way of doing things. Reviewing at a complete patch with all the modifications you have done for making shipment CRUD operations can help here getting the opinion. WDYT?


Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/ 

On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]> wrote:
Hello,

Currently I continue the conversion on shipment  crud service and I detected that many service use the same mini-lang call to check if the shipment status is ok for editing "checkCanChangeShipmentStatusPacked"

I convert it on service to call it directly by the permission-service like that :

    <service name="createShipmentPackageContent" default-entity-name="ShipmentPackageContent" engine="entity-auto" invoke="create" auth="true">...
        <permission-service service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
        <auto-attributes include="pk" mode="IN" optional="false"/>...
    </service>

The problem with this change that when I run the unit tests, I have some failed to due database lock on shipment.
After some analyse I founded that the permission service wasn't call on the same service's transaction.
I a realize this change :

Index: framework/service/src/org/ofbiz/service/ModelService.java
===================================================================
--- framework/service/src/org/ofbiz/service/ModelService.java    (révision 1737860)
+++ framework/service/src/org/ofbiz/service/ModelService.java    (copie de travail)
@@ -985,7 +985,7 @@
                 LocalDispatcher dispatcher = dctx.getDispatcher();
                 Map<String, Object> resp;
                 try {
-                    resp = dispatcher.runSync(permission.name, ctx, 300, true);
+                    resp = dispatcher.runSync(permission.name, ctx);
                 } catch (GenericServiceException e) {
                     Debug.logError(e, module);
                     Map<String, Object> result = ServiceUtil.returnSuccess();

All unit test pass.
Anyone know the reason to call the permission service on a new transaction ?
I couldn't spot any valid reason.

Thnaks for help ;)

Nicolas

--
#jeSuisCharlie

Nicolas Malin
Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
[hidden email]

8 rue des Déportés 37000 TOURS, 02 47 50 30 54
Apache OFBiz |  ofbiz-fr |  | réseau LE

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

taher
Hi Nicolas,

I have to note that in ModelPermission the same exact call is also made
with a new transaction. I did not dig deep into it but I advice to at least
check it over there as well. This makes me suspect that either both call
are wrong or both calls are right.

HTH

Taher Alkhateeb

On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
[hidden email]> wrote:

> Hi Nicolas,
>
> Calling it as permission service is tricky. I see the comment in
> implementation above the simple method in ShipmentServices.xml-
>
>     <!-- Check the Status of a Shipment to see if it can be changed -
> meant to be called in-line -->
>
> It was implemented with a purpose to be called inline, may be supporting
> the traditional way of doing things. Reviewing at a complete patch with all
> the modifications you have done for making shipment CRUD operations can
> help here getting the opinion. WDYT?
>
> Best regards,
>
> Pranay Pandey
> HotWax Systems
> http://www.hotwaxsystems.com/
>
> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Hello,
>>
>> Currently I continue the conversion on shipment  crud service and I
>> detected that many service use the same mini-lang call to check if the
>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>
>> I convert it on service to call it directly by the permission-service
>> like that :
>>
>>     <service name="createShipmentPackageContent"
>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>> invoke="create" auth="true">...
>>         <permission-service
>> service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
>>         <auto-attributes include="pk" mode="IN" optional="false"/>...
>>     </service>
>>
>> The problem with this change that when I run the unit tests, I have some
>> failed to due database lock on shipment.
>> After some analyse I founded that the permission service wasn't call on
>> the same service's transaction.
>> I a realize this change :
>>
>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>> ===================================================================
>> --- framework/service/src/org/ofbiz/service/ModelService.java
>> (révision 1737860)
>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>> de travail)
>> @@ -985,7 +985,7 @@
>>                  LocalDispatcher dispatcher = dctx.getDispatcher();
>>                  Map<String, Object> resp;
>>                  try {
>> -                    resp = dispatcher.runSync(permission.name, ctx,
>> 300, true);
>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>                  } catch (GenericServiceException e) {
>>                      Debug.logError(e, module);
>>                      Map<String, Object> result =
>> ServiceUtil.returnSuccess();
>>
>> All unit test pass.
>> Anyone know the reason to call the permission service on a new
>> transaction ?
>> I couldn't spot any valid reason.
>>
>> Thnaks for help ;)
>>
>> Nicolas
>>
>> --
>> #jeSuisCharlie
>> [image: logoNrd] <http://nereide.fr/>
>> Nicolas Malin
>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>> [hidden email]
>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>> <http://www.ofbiz-fr.org/> |  | réseau LE
>> <http://www.libre-entreprise.org/>
>>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
In reply to this post by Pranay Pandey-3
Hi Pranay,
Sorry for the latency
Le 15/04/2016 08:18, Pranay Pandey a écrit :

> Hi Nicolas,
>
> Calling it as permission service is tricky. I see the comment in
> implementation above the simple method in ShipmentServices.xml-
>
> <!-- Check the Status of a Shipment to see if it can be changed -
> meant to be called in-line -->
>
> It was implemented with a purpose to be called inline, may be
> supporting the traditional way of doing things
>
Yes, and it's the reason that I changed the code ;)
>
> . Reviewing at a complete patch with all the modifications you have
> done for making shipment CRUD operations can help here getting the
> opinion. WDYT?
>
With pleasure !
My reflexion is : what analyze a permission service ? If it's only the
security permission by check security group permission, run the service
permission on new transaction don't' raze problem. But if we want use
the permission service to analyze a business case to validate a service
run, we have a risk to generate some lock on service chain.

Cheers,
Nicolas

>
> Best regards,
>
> Pranay Pandey
> HotWax Systems
> http://www.hotwaxsystems.com/
>
> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin
> <[hidden email] <mailto:[hidden email]>> wrote:
>
>     Hello,
>
>     Currently I continue the conversion on shipment  crud service and
>     I detected that many service use the same mini-lang call to check
>     if the shipment status is ok for editing
>     "checkCanChangeShipmentStatusPacked"
>
>     I convert it on service to call it directly by the
>     permission-service like that :
>
>         <service name="createShipmentPackageContent"
>     default-entity-name="ShipmentPackageContent" engine="entity-auto"
>     invoke="create" auth="true">...
>             <permission-service
>     service-name="checkCanChangeShipmentStatusPacked"
>     main-action="CREATE"/>
>             <auto-attributes include="pk" mode="IN" optional="false"/>...
>         </service>
>
>     The problem with this change that when I run the unit tests, I
>     have some failed to due database lock on shipment.
>     After some analyse I founded that the permission service wasn't
>     call on the same service's transaction.
>     I a realize this change :
>
>     Index: framework/service/src/org/ofbiz/service/ModelService.java
>     ===================================================================
>     --- framework/service/src/org/ofbiz/service/ModelService.java
>     (révision 1737860)
>     +++ framework/service/src/org/ofbiz/service/ModelService.java
>     (copie de travail)
>     @@ -985,7 +985,7 @@
>                      LocalDispatcher dispatcher = dctx.getDispatcher();
>                      Map<String, Object> resp;
>                      try {
>     -                    resp = dispatcher.runSync(permission.name
>     <http://permission.name>, ctx, 300, true);
>     +                    resp = dispatcher.runSync(permission.name
>     <http://permission.name>, ctx);
>                      } catch (GenericServiceException e) {
>                          Debug.logError(e, module);
>                          Map<String, Object> result =
>     ServiceUtil.returnSuccess();
>
>     All unit test pass.
>     Anyone know the reason to call the permission service on a new
>     transaction ?
>     I couldn't spot any valid reason.
>
>     Thnaks for help ;)
>
>     Nicolas
>
>     --
>     #jeSuisCharlie
>     logoNrd <http://nereide.fr/>
>     Nicolas Malin
>     Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom
>     pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
>     [hidden email] <mailto:[hidden email]>
>     8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>
>     Apache OFBiz <http://ofbiz.apache.org/> | ofbiz-fr
>     <http://www.ofbiz-fr.org/> | | réseau LE
>     <http://www.libre-entreprise.org/>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
In reply to this post by taher
Hi Taher,

It's true :) and it's a beautiful copy paste !

Now my deep think would be that both call are wrong (not wrong but not
finalized) because the permission eval call a service. And a service
give the information if he will run on new transaction so we need to
check on the service definition. More, we can on a specific service,
call the permission service on new transaction but not on other service.

So a permission service need to analyse if the service to call require a
new transaction and improve permission service model to surcharge this.

Finally, i will open an issue to improve this ^^ .

Cheers,

Nicolas

Le 15/04/2016 08:23, Taher Alkhateeb a écrit :

> Hi Nicolas,
>
> I have to note that in ModelPermission the same exact call is also made
> with a new transaction. I did not dig deep into it but I advice to at least
> check it over there as well. This makes me suspect that either both call
> are wrong or both calls are right.
>
> HTH
>
> Taher Alkhateeb
>
> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
> [hidden email]> wrote:
>
>> Hi Nicolas,
>>
>> Calling it as permission service is tricky. I see the comment in
>> implementation above the simple method in ShipmentServices.xml-
>>
>>      <!-- Check the Status of a Shipment to see if it can be changed -
>> meant to be called in-line -->
>>
>> It was implemented with a purpose to be called inline, may be supporting
>> the traditional way of doing things. Reviewing at a complete patch with all
>> the modifications you have done for making shipment CRUD operations can
>> help here getting the opinion. WDYT?
>>
>> Best regards,
>>
>> Pranay Pandey
>> HotWax Systems
>> http://www.hotwaxsystems.com/
>>
>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
>> wrote:
>>
>>> Hello,
>>>
>>> Currently I continue the conversion on shipment  crud service and I
>>> detected that many service use the same mini-lang call to check if the
>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>
>>> I convert it on service to call it directly by the permission-service
>>> like that :
>>>
>>>      <service name="createShipmentPackageContent"
>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>> invoke="create" auth="true">...
>>>          <permission-service
>>> service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
>>>          <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>      </service>
>>>
>>> The problem with this change that when I run the unit tests, I have some
>>> failed to due database lock on shipment.
>>> After some analyse I founded that the permission service wasn't call on
>>> the same service's transaction.
>>> I a realize this change :
>>>
>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>> ===================================================================
>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>> (révision 1737860)
>>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>>> de travail)
>>> @@ -985,7 +985,7 @@
>>>                   LocalDispatcher dispatcher = dctx.getDispatcher();
>>>                   Map<String, Object> resp;
>>>                   try {
>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>> 300, true);
>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>                   } catch (GenericServiceException e) {
>>>                       Debug.logError(e, module);
>>>                       Map<String, Object> result =
>>> ServiceUtil.returnSuccess();
>>>
>>> All unit test pass.
>>> Anyone know the reason to call the permission service on a new
>>> transaction ?
>>> I couldn't spot any valid reason.
>>>
>>> Thnaks for help ;)
>>>
>>> Nicolas
>>>
>>> --
>>> #jeSuisCharlie
>>> [image: logoNrd] <http://nereide.fr/>
>>> Nicolas Malin
>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>>> <http://www.ofbiz-fr.org/> |  | réseau LE
>>> <http://www.libre-entreprise.org/>
>>>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
In reply to this post by taher
Hi all, I need some Help !! I put my arm in a gearing :(

After refactor the permission service, I raise a silent problem that is
all call-service used on mini-lang test didn't passed to service validation.

I correct some easier case like bad attribut passed but now rest some
complicate case like this :

testProductionRunCreation : Type check failed for field
[createWorkEffortGoodStandard.estimatedQuantity]; expected type is
[Double]; actual type is [java.math.BigDecimal]

The problem came from that :

  * Field has define as BigDecimal on mini-lang

  * The service definition use auto-attribute to resolve the java type

  * The field on the entity is define as floating-point and is converted
by fieldType as Double

So to reallign this I have some possibility

1. Easy : test are wrong : convert field instantiation to Double instead
of BigDecimal for all tests failed

2. Medium : service need realign : I surcharge attribute definition to
accept BigDecimal for these service

3. Hard : Why Double for floating-point, I had in my mind that
BigDecimal would be preferred to Double if is the case, we can change
all fieldType conversion to BigDecimal instead of Double and realign all
ofbiz code related.

Your suggest will be truly appreciated ;)

Nicolas

Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :

> Hi Nicolas,
>
> I have to note that in ModelPermission the same exact call is also made
> with a new transaction. I did not dig deep into it but I advice to at least
> check it over there as well. This makes me suspect that either both call
> are wrong or both calls are right.
>
> HTH
>
> Taher Alkhateeb
>
> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
> [hidden email]> wrote:
>
>> Hi Nicolas,
>>
>> Calling it as permission service is tricky. I see the comment in
>> implementation above the simple method in ShipmentServices.xml-
>>
>>      <!-- Check the Status of a Shipment to see if it can be changed -
>> meant to be called in-line -->
>>
>> It was implemented with a purpose to be called inline, may be supporting
>> the traditional way of doing things. Reviewing at a complete patch with all
>> the modifications you have done for making shipment CRUD operations can
>> help here getting the opinion. WDYT?
>>
>> Best regards,
>>
>> Pranay Pandey
>> HotWax Systems
>> http://www.hotwaxsystems.com/
>>
>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
>> wrote:
>>
>>> Hello,
>>>
>>> Currently I continue the conversion on shipment  crud service and I
>>> detected that many service use the same mini-lang call to check if the
>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>
>>> I convert it on service to call it directly by the permission-service
>>> like that :
>>>
>>>      <service name="createShipmentPackageContent"
>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>> invoke="create" auth="true">...
>>>          <permission-service
>>> service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
>>>          <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>      </service>
>>>
>>> The problem with this change that when I run the unit tests, I have some
>>> failed to due database lock on shipment.
>>> After some analyse I founded that the permission service wasn't call on
>>> the same service's transaction.
>>> I a realize this change :
>>>
>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>> ===================================================================
>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>> (révision 1737860)
>>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>>> de travail)
>>> @@ -985,7 +985,7 @@
>>>                   LocalDispatcher dispatcher = dctx.getDispatcher();
>>>                   Map<String, Object> resp;
>>>                   try {
>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>> 300, true);
>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>                   } catch (GenericServiceException e) {
>>>                       Debug.logError(e, module);
>>>                       Map<String, Object> result =
>>> ServiceUtil.returnSuccess();
>>>
>>> All unit test pass.
>>> Anyone know the reason to call the permission service on a new
>>> transaction ?
>>> I couldn't spot any valid reason.
>>>
>>> Thnaks for help ;)
>>>
>>> Nicolas
>>>
>>> --
>>> #jeSuisCharlie
>>> [image: logoNrd] <http://nereide.fr/>
>>> Nicolas Malin
>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>>> <http://www.ofbiz-fr.org/> |  | réseau LE
>>> <http://www.libre-entreprise.org/>
>>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Rishi Solanki
Nicolas,

"If you are dealing with money, or precision is a must, use BigDecimal.
Otherwise Doubles tend to be good enough." That means, for quantity fields
double should be fine. But within OFBiz, I see entities like OrderItem,
OISGIR, and many other uses BigDecimal for quantity field. But I think that
is because in orderred quantity due to Product.orderDecimalQuantity user
may enter the decimal quantity.

With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
may contains precision values in it in some business scenarios then we
should go for the #3. Or simple conversion should work as you suggested in
#1.


My suggestion is to go with #1, as I couldn't think of scenario where
precision required upto many decimal places for the
WorkEffortGoodStandard.estimatedQuantity field.

Hope its not too late for original topic in this thread, +1 for using the
same transaction for the permission services. As whenever we call
permission service in a wrapper service we always use the same transaction.

Thanks!


Best Regards,
--



Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin <[hidden email]>
wrote:

> Hi all, I need some Help !! I put my arm in a gearing :(
>
> After refactor the permission service, I raise a silent problem that is
> all call-service used on mini-lang test didn't passed to service validation.
>
> I correct some easier case like bad attribut passed but now rest some
> complicate case like this :
>
> testProductionRunCreation : Type check failed for field
> [createWorkEffortGoodStandard.estimatedQuantity]; expected type is
> [Double]; actual type is [java.math.BigDecimal]
>
> The problem came from that :
>
>  * Field has define as BigDecimal on mini-lang
>
>  * The service definition use auto-attribute to resolve the java type
>
>  * The field on the entity is define as floating-point and is converted by
> fieldType as Double
>
> So to reallign this I have some possibility
>
> 1. Easy : test are wrong : convert field instantiation to Double instead
> of BigDecimal for all tests failed
>
> 2. Medium : service need realign : I surcharge attribute definition to
> accept BigDecimal for these service
>
> 3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
> would be preferred to Double if is the case, we can change all fieldType
> conversion to BigDecimal instead of Double and realign all ofbiz code
> related.
>
> Your suggest will be truly appreciated ;)
>
> Nicolas
>
>
> Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :
>
>> Hi Nicolas,
>>
>> I have to note that in ModelPermission the same exact call is also made
>> with a new transaction. I did not dig deep into it but I advice to at
>> least
>> check it over there as well. This makes me suspect that either both call
>> are wrong or both calls are right.
>>
>> HTH
>>
>> Taher Alkhateeb
>>
>> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
>> [hidden email]> wrote:
>>
>> Hi Nicolas,
>>>
>>> Calling it as permission service is tricky. I see the comment in
>>> implementation above the simple method in ShipmentServices.xml-
>>>
>>>      <!-- Check the Status of a Shipment to see if it can be changed -
>>> meant to be called in-line -->
>>>
>>> It was implemented with a purpose to be called inline, may be supporting
>>> the traditional way of doing things. Reviewing at a complete patch with
>>> all
>>> the modifications you have done for making shipment CRUD operations can
>>> help here getting the opinion. WDYT?
>>>
>>> Best regards,
>>>
>>> Pranay Pandey
>>> HotWax Systems
>>> http://www.hotwaxsystems.com/
>>>
>>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
>>> wrote:
>>>
>>> Hello,
>>>>
>>>> Currently I continue the conversion on shipment  crud service and I
>>>> detected that many service use the same mini-lang call to check if the
>>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>>
>>>> I convert it on service to call it directly by the permission-service
>>>> like that :
>>>>
>>>>      <service name="createShipmentPackageContent"
>>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>>> invoke="create" auth="true">...
>>>>          <permission-service
>>>> service-name="checkCanChangeShipmentStatusPacked"
>>>> main-action="CREATE"/>
>>>>          <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>>      </service>
>>>>
>>>> The problem with this change that when I run the unit tests, I have some
>>>> failed to due database lock on shipment.
>>>> After some analyse I founded that the permission service wasn't call on
>>>> the same service's transaction.
>>>> I a realize this change :
>>>>
>>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>>> ===================================================================
>>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>>> (révision 1737860)
>>>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>>>> de travail)
>>>> @@ -985,7 +985,7 @@
>>>>                   LocalDispatcher dispatcher = dctx.getDispatcher();
>>>>                   Map<String, Object> resp;
>>>>                   try {
>>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>>> 300, true);
>>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>>                   } catch (GenericServiceException e) {
>>>>                       Debug.logError(e, module);
>>>>                       Map<String, Object> result =
>>>> ServiceUtil.returnSuccess();
>>>>
>>>> All unit test pass.
>>>> Anyone know the reason to call the permission service on a new
>>>> transaction ?
>>>> I couldn't spot any valid reason.
>>>>
>>>> Thnaks for help ;)
>>>>
>>>> Nicolas
>>>>
>>>> --
>>>> #jeSuisCharlie
>>>> [image: logoNrd] <http://nereide.fr/>
>>>> Nicolas Malin
>>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>>> [hidden email]
>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>>>> <http://www.ofbiz-fr.org/> |  | réseau LE
>>>> <http://www.libre-entreprise.org/>
>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Jacques Le Roux
Administrator
This could be related https://issues.apache.org/jira/browse/OFBIZ-6386 (did not check anything, just a souvenir)

Jacques


Le 19/09/2016 à 16:20, Rishi Solanki a écrit :

> Nicolas,
>
> "If you are dealing with money, or precision is a must, use BigDecimal.
> Otherwise Doubles tend to be good enough." That means, for quantity fields
> double should be fine. But within OFBiz, I see entities like OrderItem,
> OISGIR, and many other uses BigDecimal for quantity field. But I think that
> is because in orderred quantity due to Product.orderDecimalQuantity user
> may enter the decimal quantity.
>
> With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
> may contains precision values in it in some business scenarios then we
> should go for the #3. Or simple conversion should work as you suggested in
> #1.
>
>
> My suggestion is to go with #1, as I couldn't think of scenario where
> precision required upto many decimal places for the
> WorkEffortGoodStandard.estimatedQuantity field.
>
> Hope its not too late for original topic in this thread, +1 for using the
> same transaction for the permission services. As whenever we call
> permission service in a wrapper service we always use the same transaction.
>
> Thanks!
>
>
> Best Regards,
> --
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Hi all, I need some Help !! I put my arm in a gearing :(
>>
>> After refactor the permission service, I raise a silent problem that is
>> all call-service used on mini-lang test didn't passed to service validation.
>>
>> I correct some easier case like bad attribut passed but now rest some
>> complicate case like this :
>>
>> testProductionRunCreation : Type check failed for field
>> [createWorkEffortGoodStandard.estimatedQuantity]; expected type is
>> [Double]; actual type is [java.math.BigDecimal]
>>
>> The problem came from that :
>>
>>   * Field has define as BigDecimal on mini-lang
>>
>>   * The service definition use auto-attribute to resolve the java type
>>
>>   * The field on the entity is define as floating-point and is converted by
>> fieldType as Double
>>
>> So to reallign this I have some possibility
>>
>> 1. Easy : test are wrong : convert field instantiation to Double instead
>> of BigDecimal for all tests failed
>>
>> 2. Medium : service need realign : I surcharge attribute definition to
>> accept BigDecimal for these service
>>
>> 3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
>> would be preferred to Double if is the case, we can change all fieldType
>> conversion to BigDecimal instead of Double and realign all ofbiz code
>> related.
>>
>> Your suggest will be truly appreciated ;)
>>
>> Nicolas
>>
>>
>> Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :
>>
>>> Hi Nicolas,
>>>
>>> I have to note that in ModelPermission the same exact call is also made
>>> with a new transaction. I did not dig deep into it but I advice to at
>>> least
>>> check it over there as well. This makes me suspect that either both call
>>> are wrong or both calls are right.
>>>
>>> HTH
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
>>> [hidden email]> wrote:
>>>
>>> Hi Nicolas,
>>>> Calling it as permission service is tricky. I see the comment in
>>>> implementation above the simple method in ShipmentServices.xml-
>>>>
>>>>       <!-- Check the Status of a Shipment to see if it can be changed -
>>>> meant to be called in-line -->
>>>>
>>>> It was implemented with a purpose to be called inline, may be supporting
>>>> the traditional way of doing things. Reviewing at a complete patch with
>>>> all
>>>> the modifications you have done for making shipment CRUD operations can
>>>> help here getting the opinion. WDYT?
>>>>
>>>> Best regards,
>>>>
>>>> Pranay Pandey
>>>> HotWax Systems
>>>> http://www.hotwaxsystems.com/
>>>>
>>>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
>>>> wrote:
>>>>
>>>> Hello,
>>>>> Currently I continue the conversion on shipment  crud service and I
>>>>> detected that many service use the same mini-lang call to check if the
>>>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>>>
>>>>> I convert it on service to call it directly by the permission-service
>>>>> like that :
>>>>>
>>>>>       <service name="createShipmentPackageContent"
>>>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>>>> invoke="create" auth="true">...
>>>>>           <permission-service
>>>>> service-name="checkCanChangeShipmentStatusPacked"
>>>>> main-action="CREATE"/>
>>>>>           <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>>>       </service>
>>>>>
>>>>> The problem with this change that when I run the unit tests, I have some
>>>>> failed to due database lock on shipment.
>>>>> After some analyse I founded that the permission service wasn't call on
>>>>> the same service's transaction.
>>>>> I a realize this change :
>>>>>
>>>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>>>> ===================================================================
>>>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>>>> (révision 1737860)
>>>>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>>>>> de travail)
>>>>> @@ -985,7 +985,7 @@
>>>>>                    LocalDispatcher dispatcher = dctx.getDispatcher();
>>>>>                    Map<String, Object> resp;
>>>>>                    try {
>>>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>>>> 300, true);
>>>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>>>                    } catch (GenericServiceException e) {
>>>>>                        Debug.logError(e, module);
>>>>>                        Map<String, Object> result =
>>>>> ServiceUtil.returnSuccess();
>>>>>
>>>>> All unit test pass.
>>>>> Anyone know the reason to call the permission service on a new
>>>>> transaction ?
>>>>> I couldn't spot any valid reason.
>>>>>
>>>>> Thnaks for help ;)
>>>>>
>>>>> Nicolas
>>>>>
>>>>> --
>>>>> #jeSuisCharlie
>>>>> [image: logoNrd] <http://nereide.fr/>
>>>>> Nicolas Malin
>>>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>>>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>>>> [hidden email]
>>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>>>>> <http://www.ofbiz-fr.org/> |  | réseau LE
>>>>> <http://www.libre-entreprise.org/>
>>>>>
>>>>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Pierre Smits
In reply to this post by Rishi Solanki
The estimate quantity is coming from manufacturing where the calculation of
quantities in tasks and production runs is based on fractions register in
product associations (BoM).

So simplification doesn't work.

Best regards,.

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Mon, Sep 19, 2016 at 4:20 PM, Rishi Solanki <[hidden email]>
wrote:

> Nicolas,
>
> "If you are dealing with money, or precision is a must, use BigDecimal.
> Otherwise Doubles tend to be good enough." That means, for quantity fields
> double should be fine. But within OFBiz, I see entities like OrderItem,
> OISGIR, and many other uses BigDecimal for quantity field. But I think that
> is because in orderred quantity due to Product.orderDecimalQuantity user
> may enter the decimal quantity.
>
> With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
> may contains precision values in it in some business scenarios then we
> should go for the #3. Or simple conversion should work as you suggested in
> #1.
>
>
> My suggestion is to go with #1, as I couldn't think of scenario where
> precision required upto many decimal places for the
> WorkEffortGoodStandard.estimatedQuantity field.
>
> Hope its not too late for original topic in this thread, +1 for using the
> same transaction for the permission services. As whenever we call
> permission service in a wrapper service we always use the same transaction.
>
> Thanks!
>
>
> Best Regards,
> --
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin <[hidden email]>
> wrote:
>
> > Hi all, I need some Help !! I put my arm in a gearing :(
> >
> > After refactor the permission service, I raise a silent problem that is
> > all call-service used on mini-lang test didn't passed to service
> validation.
> >
> > I correct some easier case like bad attribut passed but now rest some
> > complicate case like this :
> >
> > testProductionRunCreation : Type check failed for field
> > [createWorkEffortGoodStandard.estimatedQuantity]; expected type is
> > [Double]; actual type is [java.math.BigDecimal]
> >
> > The problem came from that :
> >
> >  * Field has define as BigDecimal on mini-lang
> >
> >  * The service definition use auto-attribute to resolve the java type
> >
> >  * The field on the entity is define as floating-point and is converted
> by
> > fieldType as Double
> >
> > So to reallign this I have some possibility
> >
> > 1. Easy : test are wrong : convert field instantiation to Double instead
> > of BigDecimal for all tests failed
> >
> > 2. Medium : service need realign : I surcharge attribute definition to
> > accept BigDecimal for these service
> >
> > 3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
> > would be preferred to Double if is the case, we can change all fieldType
> > conversion to BigDecimal instead of Double and realign all ofbiz code
> > related.
> >
> > Your suggest will be truly appreciated ;)
> >
> > Nicolas
> >
> >
> > Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :
> >
> >> Hi Nicolas,
> >>
> >> I have to note that in ModelPermission the same exact call is also made
> >> with a new transaction. I did not dig deep into it but I advice to at
> >> least
> >> check it over there as well. This makes me suspect that either both call
> >> are wrong or both calls are right.
> >>
> >> HTH
> >>
> >> Taher Alkhateeb
> >>
> >> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
> >> [hidden email]> wrote:
> >>
> >> Hi Nicolas,
> >>>
> >>> Calling it as permission service is tricky. I see the comment in
> >>> implementation above the simple method in ShipmentServices.xml-
> >>>
> >>>      <!-- Check the Status of a Shipment to see if it can be changed -
> >>> meant to be called in-line -->
> >>>
> >>> It was implemented with a purpose to be called inline, may be
> supporting
> >>> the traditional way of doing things. Reviewing at a complete patch with
> >>> all
> >>> the modifications you have done for making shipment CRUD operations can
> >>> help here getting the opinion. WDYT?
> >>>
> >>> Best regards,
> >>>
> >>> Pranay Pandey
> >>> HotWax Systems
> >>> http://www.hotwaxsystems.com/
> >>>
> >>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <
> [hidden email]>
> >>> wrote:
> >>>
> >>> Hello,
> >>>>
> >>>> Currently I continue the conversion on shipment  crud service and I
> >>>> detected that many service use the same mini-lang call to check if the
> >>>> shipment status is ok for editing "checkCanChangeShipmentStatusPa
> cked"
> >>>>
> >>>> I convert it on service to call it directly by the permission-service
> >>>> like that :
> >>>>
> >>>>      <service name="createShipmentPackageContent"
> >>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
> >>>> invoke="create" auth="true">...
> >>>>          <permission-service
> >>>> service-name="checkCanChangeShipmentStatusPacked"
> >>>> main-action="CREATE"/>
> >>>>          <auto-attributes include="pk" mode="IN" optional="false"/>...
> >>>>      </service>
> >>>>
> >>>> The problem with this change that when I run the unit tests, I have
> some
> >>>> failed to due database lock on shipment.
> >>>> After some analyse I founded that the permission service wasn't call
> on
> >>>> the same service's transaction.
> >>>> I a realize this change :
> >>>>
> >>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
> >>>> ===================================================================
> >>>> --- framework/service/src/org/ofbiz/service/ModelService.java
> >>>> (révision 1737860)
> >>>> +++ framework/service/src/org/ofbiz/service/ModelService.java
> (copie
> >>>> de travail)
> >>>> @@ -985,7 +985,7 @@
> >>>>                   LocalDispatcher dispatcher = dctx.getDispatcher();
> >>>>                   Map<String, Object> resp;
> >>>>                   try {
> >>>> -                    resp = dispatcher.runSync(permission.name, ctx,
> >>>> 300, true);
> >>>> +                    resp = dispatcher.runSync(permission.name, ctx);
> >>>>                   } catch (GenericServiceException e) {
> >>>>                       Debug.logError(e, module);
> >>>>                       Map<String, Object> result =
> >>>> ServiceUtil.returnSuccess();
> >>>>
> >>>> All unit test pass.
> >>>> Anyone know the reason to call the permission service on a new
> >>>> transaction ?
> >>>> I couldn't spot any valid reason.
> >>>>
> >>>> Thnaks for help ;)
> >>>>
> >>>> Nicolas
> >>>>
> >>>> --
> >>>> #jeSuisCharlie
> >>>> [image: logoNrd] <http://nereide.fr/>
> >>>> Nicolas Malin
> >>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom
> pouvent
> >>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
> >>>> [hidden email]
> >>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
> >>>> <http://www.ofbiz-fr.org/> |  | réseau LE
> >>>> <http://www.libre-entreprise.org/>
> >>>>
> >>>>
> >>>
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
In reply to this post by Rishi Solanki
Hi Rishi,

in line

Le 19/09/2016 à 16:20, Rishi Solanki a écrit :

> Nicolas,
>
> "If you are dealing with money, or precision is a must, use BigDecimal.
> Otherwise Doubles tend to be good enough." That means, for quantity fields
> double should be fine. But within OFBiz, I see entities like OrderItem,
> OISGIR, and many other uses BigDecimal for quantity field. But I think that
> is because in orderred quantity due to Product.orderDecimalQuantity user
> may enter the decimal quantity.
>
> With all this said, if we think WorkEffortGoodStandard.estimatedQuantity
> may contains precision values in it in some business scenarios then we
> should go for the #3. Or simple conversion should work as you suggested in
> #1.
Sure the #3 would be the better choice, but the step is hard ! I agree
with you to move on first stable point, and close this too long task.
> My suggestion is to go with #1, as I couldn't think of scenario where
> precision required upto many decimal places for the
> WorkEffortGoodStandard.estimatedQuantity field.
>
> Hope its not too late for original topic in this thread, +1 for using the
> same transaction for the permission services. As whenever we call
> permission service in a wrapper service we always use the same transaction.
It's never too late ;) , I continue the work and add new parameter on
permission service to give the possibility to use or not the same
transaction. But by default don't use the same.

If you want look forward, I create a branch permission-same-transaction
on github.com:nmalin/ApacheOFBiz.git to work easily on it.

Nicolas

>
> Thanks!
>
>
> Best Regards,
> --
>
>
>
> Rishi Solanki
> Manager, Enterprise Software Development
> HotWax Systems Pvt. Ltd.
> Direct: +91-9893287847
> http://www.hotwaxsystems.com
>
> On Sat, Sep 17, 2016 at 5:30 PM, Nicolas Malin <[hidden email]>
> wrote:
>
>> Hi all, I need some Help !! I put my arm in a gearing :(
>>
>> After refactor the permission service, I raise a silent problem that is
>> all call-service used on mini-lang test didn't passed to service validation.
>>
>> I correct some easier case like bad attribut passed but now rest some
>> complicate case like this :
>>
>> testProductionRunCreation : Type check failed for field
>> [createWorkEffortGoodStandard.estimatedQuantity]; expected type is
>> [Double]; actual type is [java.math.BigDecimal]
>>
>> The problem came from that :
>>
>>   * Field has define as BigDecimal on mini-lang
>>
>>   * The service definition use auto-attribute to resolve the java type
>>
>>   * The field on the entity is define as floating-point and is converted by
>> fieldType as Double
>>
>> So to reallign this I have some possibility
>>
>> 1. Easy : test are wrong : convert field instantiation to Double instead
>> of BigDecimal for all tests failed
>>
>> 2. Medium : service need realign : I surcharge attribute definition to
>> accept BigDecimal for these service
>>
>> 3. Hard : Why Double for floating-point, I had in my mind that BigDecimal
>> would be preferred to Double if is the case, we can change all fieldType
>> conversion to BigDecimal instead of Double and realign all ofbiz code
>> related.
>>
>> Your suggest will be truly appreciated ;)
>>
>> Nicolas
>>
>>
>> Le 15/04/2016 à 08:23, Taher Alkhateeb a écrit :
>>
>>> Hi Nicolas,
>>>
>>> I have to note that in ModelPermission the same exact call is also made
>>> with a new transaction. I did not dig deep into it but I advice to at
>>> least
>>> check it over there as well. This makes me suspect that either both call
>>> are wrong or both calls are right.
>>>
>>> HTH
>>>
>>> Taher Alkhateeb
>>>
>>> On Fri, Apr 15, 2016 at 9:18 AM, Pranay Pandey <
>>> [hidden email]> wrote:
>>>
>>> Hi Nicolas,
>>>> Calling it as permission service is tricky. I see the comment in
>>>> implementation above the simple method in ShipmentServices.xml-
>>>>
>>>>       <!-- Check the Status of a Shipment to see if it can be changed -
>>>> meant to be called in-line -->
>>>>
>>>> It was implemented with a purpose to be called inline, may be supporting
>>>> the traditional way of doing things. Reviewing at a complete patch with
>>>> all
>>>> the modifications you have done for making shipment CRUD operations can
>>>> help here getting the opinion. WDYT?
>>>>
>>>> Best regards,
>>>>
>>>> Pranay Pandey
>>>> HotWax Systems
>>>> http://www.hotwaxsystems.com/
>>>>
>>>> On Thu, Apr 7, 2016 at 1:30 PM, Nicolas Malin <[hidden email]>
>>>> wrote:
>>>>
>>>> Hello,
>>>>> Currently I continue the conversion on shipment  crud service and I
>>>>> detected that many service use the same mini-lang call to check if the
>>>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>>>
>>>>> I convert it on service to call it directly by the permission-service
>>>>> like that :
>>>>>
>>>>>       <service name="createShipmentPackageContent"
>>>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>>>> invoke="create" auth="true">...
>>>>>           <permission-service
>>>>> service-name="checkCanChangeShipmentStatusPacked"
>>>>> main-action="CREATE"/>
>>>>>           <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>>>       </service>
>>>>>
>>>>> The problem with this change that when I run the unit tests, I have some
>>>>> failed to due database lock on shipment.
>>>>> After some analyse I founded that the permission service wasn't call on
>>>>> the same service's transaction.
>>>>> I a realize this change :
>>>>>
>>>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>>>> ===================================================================
>>>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>>>> (révision 1737860)
>>>>> +++ framework/service/src/org/ofbiz/service/ModelService.java    (copie
>>>>> de travail)
>>>>> @@ -985,7 +985,7 @@
>>>>>                    LocalDispatcher dispatcher = dctx.getDispatcher();
>>>>>                    Map<String, Object> resp;
>>>>>                    try {
>>>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>>>> 300, true);
>>>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>>>                    } catch (GenericServiceException e) {
>>>>>                        Debug.logError(e, module);
>>>>>                        Map<String, Object> result =
>>>>> ServiceUtil.returnSuccess();
>>>>>
>>>>> All unit test pass.
>>>>> Anyone know the reason to call the permission service on a new
>>>>> transaction ?
>>>>> I couldn't spot any valid reason.
>>>>>
>>>>> Thnaks for help ;)
>>>>>
>>>>> Nicolas
>>>>>
>>>>> --
>>>>> #jeSuisCharlie
>>>>> [image: logoNrd] <http://nereide.fr/>
>>>>> Nicolas Malin
>>>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom pouvent
>>>>> trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>>>> [hidden email]
>>>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>>> Apache OFBiz <http://ofbiz.apache.org/> |  ofbiz-fr
>>>>> <http://www.ofbiz-fr.org/> |  | réseau LE
>>>>> <http://www.libre-entreprise.org/>
>>>>>
>>>>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

jleroux-2
In reply to this post by Nicolas Malin-2
Hi Nicolas,

Just stumbled upon this. Is there a Jira? What is the revision commit number?

Thanks
Jacques (sent from PonyMail)

On 2016-04-14 21:03, Nicolas Malin <[hidden email]> wrote:

> No remarks on this case ?
>
> If the silent is present I open an issue and commit this patch ;)
>
> Nicolas
>
> Le 07/04/2016 10:00, Nicolas Malin a écrit :
> > Hello,
> >
> > Currently I continue the conversion on shipment  crud service and I
> > detected that many service use the same mini-lang call to check if the
> > shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
> >
> > I convert it on service to call it directly by the permission-service
> > like that :
> >
> >     <service name="createShipmentPackageContent"
> > default-entity-name="ShipmentPackageContent" engine="entity-auto"
> > invoke="create" auth="true">...
> >         <permission-service
> > service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
> >         <auto-attributes include="pk" mode="IN" optional="false"/>...
> >     </service>
> >
> > The problem with this change that when I run the unit tests, I have
> > some failed to due database lock on shipment.
> > After some analyse I founded that the permission service wasn't call
> > on the same service's transaction.
> > I a realize this change :
> >
> > Index: framework/service/src/org/ofbiz/service/ModelService.java
> > ===================================================================
> > --- framework/service/src/org/ofbiz/service/ModelService.java
> > (révision 1737860)
> > +++ framework/service/src/org/ofbiz/service/ModelService.java (copie
> > de travail)
> > @@ -985,7 +985,7 @@
> >                  LocalDispatcher dispatcher = dctx.getDispatcher();
> >                  Map<String, Object> resp;
> >                  try {
> > -                    resp = dispatcher.runSync(permission.name, ctx,
> > 300, true);
> > +                    resp = dispatcher.runSync(permission.name, ctx);
> >                  } catch (GenericServiceException e) {
> >                      Debug.logError(e, module);
> >                      Map<String, Object> result =
> > ServiceUtil.returnSuccess();
> >
> > All unit test pass.
> > Anyone know the reason to call the permission service on a new
> > transaction ?
> > I couldn't spot any valid reason.
> >
> > Thnaks for help ;)
> >
> > Nicolas
> >
> > --
> > #jeSuisCharlie
> > logoNrd <http://nereide.fr/>
> > Nicolas Malin
> > Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom
> > pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
> > [hidden email]
> > 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
> >
> > Apache OFBiz <http://ofbiz.apache.org/> | ofbiz-fr
> > <http://www.ofbiz-fr.org/> | | réseau LE
> > <http://www.libre-entreprise.org/>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Permission service not on the same transaction

Nicolas Malin-2
Hi Jacques,

All is present on the issue OFBIZ-7113
<https://issues.apache.org/jira/browse/OFBIZ-7113>

But I think the patch doesn't up to date.
It contains big change, I will review quietly if you think it would be a
good improvement

Nicolas
Le 12/08/2017 à 10:23, Jacques Le Roux a écrit :

> Hi Nicolas,
>
> Just stumbled upon this. Is there a Jira? What is the revision commit number?
>
> Thanks
> Jacques (sent from PonyMail)
>
> On 2016-04-14 21:03, Nicolas Malin <[hidden email]> wrote:
>> No remarks on this case ?
>>
>> If the silent is present I open an issue and commit this patch ;)
>>
>> Nicolas
>>
>> Le 07/04/2016 10:00, Nicolas Malin a écrit :
>>> Hello,
>>>
>>> Currently I continue the conversion on shipment  crud service and I
>>> detected that many service use the same mini-lang call to check if the
>>> shipment status is ok for editing "checkCanChangeShipmentStatusPacked"
>>>
>>> I convert it on service to call it directly by the permission-service
>>> like that :
>>>
>>>      <service name="createShipmentPackageContent"
>>> default-entity-name="ShipmentPackageContent" engine="entity-auto"
>>> invoke="create" auth="true">...
>>>          <permission-service
>>> service-name="checkCanChangeShipmentStatusPacked" main-action="CREATE"/>
>>>          <auto-attributes include="pk" mode="IN" optional="false"/>...
>>>      </service>
>>>
>>> The problem with this change that when I run the unit tests, I have
>>> some failed to due database lock on shipment.
>>> After some analyse I founded that the permission service wasn't call
>>> on the same service's transaction.
>>> I a realize this change :
>>>
>>> Index: framework/service/src/org/ofbiz/service/ModelService.java
>>> ===================================================================
>>> --- framework/service/src/org/ofbiz/service/ModelService.java
>>> (révision 1737860)
>>> +++ framework/service/src/org/ofbiz/service/ModelService.java (copie
>>> de travail)
>>> @@ -985,7 +985,7 @@
>>>                   LocalDispatcher dispatcher = dctx.getDispatcher();
>>>                   Map<String, Object> resp;
>>>                   try {
>>> -                    resp = dispatcher.runSync(permission.name, ctx,
>>> 300, true);
>>> +                    resp = dispatcher.runSync(permission.name, ctx);
>>>                   } catch (GenericServiceException e) {
>>>                       Debug.logError(e, module);
>>>                       Map<String, Object> result =
>>> ServiceUtil.returnSuccess();
>>>
>>> All unit test pass.
>>> Anyone know the reason to call the permission service on a new
>>> transaction ?
>>> I couldn't spot any valid reason.
>>>
>>> Thnaks for help ;)
>>>
>>> Nicolas
>>>
>>> --
>>> #jeSuisCharlie
>>> logoNrd <http://nereide.fr/>
>>> Nicolas Malin
>>> Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom
>>> pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose
>>> [hidden email]
>>> 8 rue des Déportés 37000 TOURS, 02 47 50 30 54
>>>
>>> Apache OFBiz <http://ofbiz.apache.org/> | ofbiz-fr
>>> <http://www.ofbiz-fr.org/> | | réseau LE
>>> <http://www.libre-entreprise.org/>
>>

Loading...