Extension keeps managed entities when calling @EJB

[Fagner Brack]

I am not familiarized with the specifics of the J2EE implementation. But the test below fails when used in conjunction with this arquillian extension (part of the code apparently non relevant is ommited):

...

@EJB
ProblemReader problemReader;

...

@Test
    public void testEntityNotInPersistenceContext() throws PermissionDeniedException {

        UserSessionData user = ProblemTestHelper
                .createTestUser( 1, PermissionsWrite.ADD_NEW_PROBLEM );

        ProblemEntity problem = new ProblemEntity();
        problem.setTitle( "test" );

        problemCreator.createProblem( problem, user );

        ProblemEntity firstProblem = problemReader.getProblemByPrimaryKey( 1 );
        Assert.assertEquals( "test", firstProblem.getTitle() );

        firstProblem.setTitle( "newtitle" );

        ProblemEntity secondProblem = problemReader.getProblemByPrimaryKey( 1 );
        Assert.assertEquals( "test", secondProblem.getTitle() );
    }

...

I suppose secondProblem.getTitle() should be "test" but it is actually receiving "newtest". It only happens if I use the following annotations in the class level:

@ApplyScriptBefore( "create-schema.sql" )
@ApplyScriptAfter( "drop-schema.sql" )

That eventually enables the extension. When I remove those the test is completed successfully.

[Bartosz Majsak]

How does the Reader look like from the transaction perspective? Does it simply join if transaction exists? If so that is the case. It's becuase of the first level cache, which is evicted as soon as the transaction has ended. By convention persistence tests are wrapped in transaction. You can change it by settings @transactional(DISABLED).

However it got me thinking if that should be the case when the only thing you need it applying some scripts... need to re-think it. Thanks for sharing the use case.

If I may suggest something for the future - please use jboss forum for such questions. I guess it's better suited for "support" :)

[Fagner Brack]

Actually this looks like an issue to me instead of a regular question, that is why I posted here.

In my point of view the expectation of a user is the test content to behave exactly as if arquillian persistence API is not being used. In this case I want to test if a given @EJB is staying managed in another container (I want to use arquillian also to learn how the system works in a practical way).
In this case, I expect the junit test content not to be wrapped in a transaction but just do the necessary for the scripts to be executed.

Can this be considered a bug? The tests are behaving in a unexpected way if and only if I enable the arquillian persistence API.

By convention persistence tests are wrapped in transaction

I suppose this use case conflicts with the actual convention. And the solution would require new code to be added.

Thanks.

[Bartosz Majsak]

With regards to wrapping in the transaction, if you seed something in the database it's more common that your test needs to run in the transaction as you interact with the persistence layer (and you probably assume that caller of your EJB runs in transaction already). But maybe this should be narrowed only for per-test-method usage... I need to think about it. Thx for some food for thoughts.

However I don't see it as a bug to be honest (at least not yet ;). Anyways - I will chew it over and go back to you soon. For the time being please disable transactions (can be done on the class level to not repeat yourself for each and every test).

[Fagner Brack]

Ok then, for the time being I will disable the transactions when such case is required.

[Bartosz Majsak]

Are you still facing the problem? Otherwise I would like to close this issue if the new version is not having mentioned problem

[Fagner Brack]

Unfortunately I am not able to check if the problem still exists because it's been a long time since it was reported and I am not even working with Java anymore.

In the end it is up to you to decide if there are enough informations that justify this issue to stay open or not based in the potential benefit for the extension :)

[Bartosz Majsak]

Fair enough. Will try to investigate :)