EJB Singleton - Lock READ method calling a Lock WRITE method of the same instance












1















Given a Singleton like this one:



@Singleton
public class waitingTimeManager {

private Map<Integer, Object> waitingTimes;

@PostConstruct
public void setup() {
waitingTimes = new HashMap<>();
}

@Lock(LockType.READ)
public boolean shouldWeWait(Integer id) {
if (waitingTimes.containsKey(id)) {
boolean wait = someLogic(waitingTimes.get(id));
if (!wait) {
// we don't need to wait for it anymore
stopWaiting(id);
}
return wait;
}
return false;
}

@Lock(LockType.WRITE)
public void stopWaiting(Integer id){
waitingTimes.remove(id);
}

}


The initial method shouldWeWait can be accessed at the same time by several threads. The other stopWaiting will need to get a write lock.



Will the call to stopWaiting inside shouldWeWait try to get a WRITE Lock? or simply execute it as it already got the READ Lock initially?










share|improve this question




















  • 2





    AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

    – Meini
    Nov 15 '18 at 10:16
















1















Given a Singleton like this one:



@Singleton
public class waitingTimeManager {

private Map<Integer, Object> waitingTimes;

@PostConstruct
public void setup() {
waitingTimes = new HashMap<>();
}

@Lock(LockType.READ)
public boolean shouldWeWait(Integer id) {
if (waitingTimes.containsKey(id)) {
boolean wait = someLogic(waitingTimes.get(id));
if (!wait) {
// we don't need to wait for it anymore
stopWaiting(id);
}
return wait;
}
return false;
}

@Lock(LockType.WRITE)
public void stopWaiting(Integer id){
waitingTimes.remove(id);
}

}


The initial method shouldWeWait can be accessed at the same time by several threads. The other stopWaiting will need to get a write lock.



Will the call to stopWaiting inside shouldWeWait try to get a WRITE Lock? or simply execute it as it already got the READ Lock initially?










share|improve this question




















  • 2





    AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

    – Meini
    Nov 15 '18 at 10:16














1












1








1


1






Given a Singleton like this one:



@Singleton
public class waitingTimeManager {

private Map<Integer, Object> waitingTimes;

@PostConstruct
public void setup() {
waitingTimes = new HashMap<>();
}

@Lock(LockType.READ)
public boolean shouldWeWait(Integer id) {
if (waitingTimes.containsKey(id)) {
boolean wait = someLogic(waitingTimes.get(id));
if (!wait) {
// we don't need to wait for it anymore
stopWaiting(id);
}
return wait;
}
return false;
}

@Lock(LockType.WRITE)
public void stopWaiting(Integer id){
waitingTimes.remove(id);
}

}


The initial method shouldWeWait can be accessed at the same time by several threads. The other stopWaiting will need to get a write lock.



Will the call to stopWaiting inside shouldWeWait try to get a WRITE Lock? or simply execute it as it already got the READ Lock initially?










share|improve this question
















Given a Singleton like this one:



@Singleton
public class waitingTimeManager {

private Map<Integer, Object> waitingTimes;

@PostConstruct
public void setup() {
waitingTimes = new HashMap<>();
}

@Lock(LockType.READ)
public boolean shouldWeWait(Integer id) {
if (waitingTimes.containsKey(id)) {
boolean wait = someLogic(waitingTimes.get(id));
if (!wait) {
// we don't need to wait for it anymore
stopWaiting(id);
}
return wait;
}
return false;
}

@Lock(LockType.WRITE)
public void stopWaiting(Integer id){
waitingTimes.remove(id);
}

}


The initial method shouldWeWait can be accessed at the same time by several threads. The other stopWaiting will need to get a write lock.



Will the call to stopWaiting inside shouldWeWait try to get a WRITE Lock? or simply execute it as it already got the READ Lock initially?







java concurrency singleton ejb






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 15 '18 at 10:20







Daniel Rodríguez

















asked Nov 15 '18 at 10:06









Daniel RodríguezDaniel Rodríguez

1531316




1531316








  • 2





    AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

    – Meini
    Nov 15 '18 at 10:16














  • 2





    AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

    – Meini
    Nov 15 '18 at 10:16








2




2





AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

– Meini
Nov 15 '18 at 10:16





AFAIK the @Lock on stopWaiting is not recognized since you have to invoke it on the business object and not on this.

– Meini
Nov 15 '18 at 10:16












1 Answer
1






active

oldest

votes


















3














No, it won't try to get write lock.



Container job is done within interceptors, wrapping EJB method calls. For example, when stateless BeanA calls your singleton - it does so through proxy, which makes possible the guarantees given by container (retrieving lock, etc.).



But in this case, it's just a normal method call (stopWaiting), not wrapped by proxy, so no place for magic.






share|improve this answer























    Your Answer






    StackExchange.ifUsing("editor", function () {
    StackExchange.using("externalEditor", function () {
    StackExchange.using("snippets", function () {
    StackExchange.snippets.init();
    });
    });
    }, "code-snippets");

    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "1"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: true,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: 10,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316923%2fejb-singleton-lock-read-method-calling-a-lock-write-method-of-the-same-instanc%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    3














    No, it won't try to get write lock.



    Container job is done within interceptors, wrapping EJB method calls. For example, when stateless BeanA calls your singleton - it does so through proxy, which makes possible the guarantees given by container (retrieving lock, etc.).



    But in this case, it's just a normal method call (stopWaiting), not wrapped by proxy, so no place for magic.






    share|improve this answer




























      3














      No, it won't try to get write lock.



      Container job is done within interceptors, wrapping EJB method calls. For example, when stateless BeanA calls your singleton - it does so through proxy, which makes possible the guarantees given by container (retrieving lock, etc.).



      But in this case, it's just a normal method call (stopWaiting), not wrapped by proxy, so no place for magic.






      share|improve this answer


























        3












        3








        3







        No, it won't try to get write lock.



        Container job is done within interceptors, wrapping EJB method calls. For example, when stateless BeanA calls your singleton - it does so through proxy, which makes possible the guarantees given by container (retrieving lock, etc.).



        But in this case, it's just a normal method call (stopWaiting), not wrapped by proxy, so no place for magic.






        share|improve this answer













        No, it won't try to get write lock.



        Container job is done within interceptors, wrapping EJB method calls. For example, when stateless BeanA calls your singleton - it does so through proxy, which makes possible the guarantees given by container (retrieving lock, etc.).



        But in this case, it's just a normal method call (stopWaiting), not wrapped by proxy, so no place for magic.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Nov 15 '18 at 10:20









        user3714601user3714601

        764720




        764720
































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Stack Overflow!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53316923%2fejb-singleton-lock-read-method-calling-a-lock-write-method-of-the-same-instanc%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Xamarin.iOS Cant Deploy on Iphone

            Glorious Revolution

            Dulmage-Mendelsohn matrix decomposition in Python