1 Reply Latest reply on Sep 4, 2014 10:02 AM by Ales Justin

    AT EXIT behavior

    Ales Justin Master

      I'm trying to run some concurrency tx tests for GAE TCK.

      With GAE you're only allowed that one tx handles same entity group.

      (think of entity group as a table, for now)


      I have this rules:




              name = "entry",

              targetClass = "com.google.appengine.tck.byteman.support.ConcurrentTxServlet",

              targetMethod = "putEntity",

              targetLocation = "AT EXIT",

              action = "waitFor(\"cleanup\")"),


              name = "exit",

              targetClass = "com.google.appengine.tck.byteman.support.ConcurrentTxServlet",

              targetMethod = "cleanup",

              action = "signalWake(\"cleanup\", true)"),




      and this is the relevant code.


          protected void service(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {

              String entityGroup = req.getParameter("eg");

              String counter = req.getParameter("c");



              Entity entity = new Entity(entityGroup);

              entity.setProperty("foo", RANDOM.nextInt());



              DatastoreService ds = DatastoreServiceFactory.getDatastoreService();

              final Transaction tx = ds.beginTransaction();

              try {

                  putEntity(ds, entity);


                  resp.getWriter().write("OK" + counter);

              } catch (Exception e) {


                  resp.getWriter().write("ERROR" + counter + ":" + e.getClass());

              } finally {






          private void putEntity(DatastoreService ds, Entity entity) throws IOException {





          private void cleanup(String counter) {

              log("Counter = " + counter);



      So, I expect the first rule to block first thread,

      until a second thread arrives and fails - due to dup tx on same entity group.


      And the in the 2nd rule, the failed thread should signal to the first blocked thread that it can now proceed.


      The question is -- is this OK / gonna work?

      Or will 1st rule's "AT EXIT" also catch 2nd failing thread and make it wait -- probably forever.


      Or how to do this?



        • 1. Re: AT EXIT behavior
          Ales Justin Master

          >> An AT EXIT specifier locates a trigger point at each location in the trigger method where a normal return of control occurs (i.e. wherever there is an implicit or explicit return but not where a throw exits the method).


          So, I guess I should be fine.