Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] Fix for 455683. Add support to automatically detect the target server.

Hi Rick,

After some investigation and checking the specs I decided that EL behaviour is correct. That application used Spring for transaction management and setting server platform to None is a right solution in this case.

Thanks,
Dmitry

On 30.1.2015 16:26, Rick Curtis wrote:
Dmitry -

Have you made any progress?

Thanks,
Rick

On Thu, Jan 29, 2015 at 10:04 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote:
Hi Dmitry,

I don't have the most recent Eclipselink version, but by looking at 2.5.3 (and I believe it should be pretty close to trunk) I can't so far understand how that would happen: in EntityManagerSetupImpl class:
- updateLogins method sets the boolean flag:
        login.setUsesExternalTransactionController(transactionType == PersistenceUnitTransactionType.JTA);
- right after the call to updateLogins method, if the flag is set to false then jta is disabled:
        if (!session.getDatasourceLogin().shouldUseExternalTransactionController()) {
            session.getServerPlatform().disableJTA();
        }

May be you could step through the code in debugger and see what's going on there?

Thanks,
Andrei


On 1/29/2015 6:28 AM, Dmitry Kornilov wrote:
Hi Andrei,

I got the info from Rick Curtis that you were responsible for WLS detector implementation in EL. We have some backward compatibility issues with it (see email below).

I made a simple table to help you understand the problem. Application is deployed on WLS. There are 3 use cases with different p.xml.

Use case 1:                                     Previous Version            New Version               Suggested Change

Server platform is NOT defined in p.xml         NoServerPlatform            Weblogic_XX_Platform      Weblogic_XX_Platform
Transaction type is NOT defined in p.xml        ResourceLocal               JTA                       ResourceLocal

Use case 2:

Server platform is NOT defined in p.xml         NoServerPlatform            Weblogic_XX_Platform      Weblogic_XX_Platform
Transaction type is set to JTA in p.xml         Error (JTA cannot be        JTA                       JTA
                                                with NoServerPlatform)


Use case 3:

Server platform is set to WLS in p.xml          Weblogic_XX_Platform        Weblogic_XX_Platform      Weblogic_XX_Platform
Transaction type is NOT defined in p.xml        JTA                         JTA                       JTA

Currently we have problems with the first use case. Auto detection code forces usage of JTA transaction type which breaks compatibility with previous versions (see the table above).

All other use cases are OK because the second one was not possible with the previous version and the third one doesn't change anything.

My proposed solution is:
If a server platfrom has to be detected and transaction type is not explicitly set ResourceLocal has to be used.

As Rick said it works OK with WAS. So maybe only WLS detector code has to be fixed.

Please respond asap this is quite urgent.

Thanks!

Best regards,
Dmitry Kornilov

On 29.1.2015 02:00, Rick Curtis wrote:
Dmitry -

Based off the p.xml that you sent, I tested calling Persistence.createEntityManagerFactory(...) for a persistence unit that declares only a jta-data-source / unspecified transaction-type and I'm not seeing the same problem you encountered. I tested with both WebSphere_Liberty target server and None target server. I'll note that my test fails because EclipseLink doesn't have a datasource to use and it ignores the jta-data-source. I did find an interesting warning message[1] that seems to explain why my jta-data-source isn't being used.

If I update my application to use a non-jta-datasource it works fine with the WAS platform (it failed with None server, but that is for an unrelated reason). Needless to say, I'm confused about why I am unable to recreate your failure. I assume it has something to do with a difference between the way that WAS and WLS operate. If I were to go out on a limb, I would guess it has something to do with EntityManagerFactoryProvider.emSetupImpls and the contents of that map being shared between the WLS container created EMFs and Persistence.createEntityManagerFactory(..). Anyway, I digress.

The point is that the defaults are changing.
Fair point. I think it's also fair to consider that the old default value might not be correct? The spec mentions that if the transaction-type isn't specified in an EE container it defaults to JTA. It also mentions that if a persistence unit is using RESOURCE_LOCAL that a non-jta-datasource will be provided. That being said, the spec is vague and most of the time not breaking  a customer trumps following the spec.

I suggest changing your code the way that if server platform is NOT defined in persistence.xml then a detected platform has to use resource local transactions.
I don't really like that approach as I'm not completely certain that is the right answer. I don't know what the right answer is, but I don't like restricting target-server detection down to resource_local. Another option is to remove WLS from target server detection all together. This is a drastic change, but this would be sure to solve the problems you're having.

If you guys haven't yet, please ping Andrei Illitchev to see if he has any input. He is the one that provided guidance on the change and specifically implemented the WLS detector.

I assume you guys are trying to get final testing in before releasing 2.6.x and there is pressure to get this fixed asap so I'll be sure to stay on top of this one.

Thanks,
Rick

[1] [EL Warning]: transaction: 2015-01-28 18:18:40.974--ServerSession(-79379177)--PersistenceUnitInfo persistent.coyote has transactionType RESOURCE_LOCAL and therefore jtaDataSource will be ignored

On Wed, Jan 28, 2015 at 4:46 PM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
Hi Rick,

I don't know what was declared there. I don't have a unit test for this issue. There were a couple of applications falling with the same error message after the new EL version (with your commit) was released. I don't have access to their source code. I'll find out and let you know.

As I see the problem is in changing a default transaction manager (JTA/local resources) in server platform auto detection. It doesn't matter what was defined there. The point is that the defaults are changing.

Thanks,
Dmitry


On 28.1.2015 22:45, Rick Curtis wrote:
Dmitry -

In the failing tests, what do you have declared for a transaction-type in the persistence.xml?

Thanks,
Rick

On Wed, Jan 28, 2015 at 6:59 AM, Dmitry Kornilov <dmitry.kornilov@xxxxxxxxxx> wrote:
Hi Rick,

I am writing you because of your EclipseLink commit "1e0a8ab4   Fix for 455683. Add support to automatically detect the target server."

This change introduced quite a few compatibility problems with existing applications.

If an application is deployed on WLS server and a server platform was not explicitly set in persistence.xml then NoServerPlatform was used by EL before your commit and Weblogic_XX_Platform is used after your commit.
NoServerPlatform switches EL to use resource local transactions, Weblogic_XX_Platform uses JTA transactions.
It causes backward compatability problems. See the exception below:

Cannot use an EntityTransaction while using JTA.
at
org.eclipse.persistence.internal.jpa.transaction.JTATransactionWrapper.getTran
saction(JTATransactionWrapper.java:73)
at
org.eclipse.persistence.internal.jpa.EntityManagerImpl.getTransaction(EntityMa
nagerImpl.java:1322)

The workaround would be is adding <property name="eclipselink.target-server" value="None"/> to persistence.xml. But it would be better if it works without workarounds.

I suggest changing your code the way that if server platform is NOT defined in persistence.xml then a detected platform has to use resource local transactions.

Please respond asap this is quite urgent.

Thanks!

Best regards,
Dmitry Kornilov



--
Rick Curtis




--
Rick Curtis





--
Rick Curtis


Back to the top