1 Reply Latest reply on Oct 12, 2001 4:15 PM by callumw

    pulling the NT login name

    Graham Newbie

      In ASP vbScript this will get you the users NT login name:

      What is the java equivalent?

        • 1. Re: requirement 18.3.7 from EJB 2.1
          callumw Newbie

          My intent in first place is the requirement 9.5.3 (from EJB 2.0): "After an entity object has been removed, subsequent attempts to access the entity object by a remote client
          result in the java.rmi.NoSuchObjectException."

          The current behaviour is a TransactionRolledBackException, which is absolutely unsatisfactory. I would like to make the decision myself whether to rollback or continue the transaction. I would like to be able to code

          MyEntity x;
          try {
          x = myEntityHome.findByPrimaryKey(pk);
          } catch (ObjectNotFoundException) { // from findBy....
          throw new MyEntityNotFoundException();
          } catch (NoSuchObjectException) { // from someMethod...
          throw new MyEntityNotFoundException();
          // (treating this case as if the initial findBy... had not found the entity, as it would on the next transaction)
          // do something with x ....

          In our application there exist entity beans that are concurrently accessed by one thread and removed by another thread. This inevitable leads to the situation that sometimes the entity bean achieved by a findBy... method cannot be accessed by the subsequent method call (at the time it obtains its entity instance lock the instance no longer exists).

          One way to achieve this goal was expressed by my initial proposition, because it seems to me the NoSuchEntityException was introduced with the intention in mind to enable such solutions.

          IMHO the paragraph cited by you is in conflict with other parts of the specification and also in conflict with the intention of its makers. Please observe that at no place is being expressed a need that a NoSuchObjectException had to be connected with a rollback of the current transaction.

          I see your point in interpreting these conflicting requirements in the most restrictive way so you don't risk being accused not to fulfil the spec. Perhaps the spec should be made more precise at this point.

          Best regards,