Weblogic to Liberty w JPA upgrade - related entities intermittently not being queried

79 Views Asked by At

just a quick question please in case something stands out immediately.

We're migrating an EAR/EJB application from Weblogic 11g to latest WS Liberty (22.x) also upgrading several of the frameworks including JPA to 2.2. This also changes JPA implementation to eclipseLink. We came from com.oracle.weblogic.11g.modules:javax.persistence:1.0.0.0_1-0-2. Underlying DB is MS-SQL Server.

And I'm running into some weirdness with regards to related objects not being resolved/queried intermittently.

Just as an example we have entities where the columns hold reference data codes or similar lookups. Say I have an entity called PayemntRecordT and it has a status code which refers to a ref table that also holds a textual description. Something like this:

SQL:

CREATE TABLE [PAYMENT_RECORD_T](
    [PAYMENT_ID] [int] NOT NULL,
    ...
    [PAYMENT_STATUS_CD] [CHAR](8) NOT NULL,
    ...
    )

ALTER TABLE [PAYMENT_RECORD_T]  WITH CHECK ADD  CONSTRAINT [FK_PAYM4] FOREIGN KEY([PAYMENT_STATUS_CD])
REFERENCES [RECORD_STATUS_T] ([REC_STAT_CD])
GO

CREATE TABLE [RECORD_STATUS_T] (
    [RECORD_STAT_CD] [CHAR](8) NOT NULL,
    [RECORD_STAT_DSC] [VARCHAR](60) NOT NULL
 CONSTRAINT [PK_RECORD_STATUS_T] PRIMARY KEY CLUSTERED (
    [RECORD_STAT_CD] ASC
)WITH (PAD_INDEX = OFF...) ON [PRIMARY]
) ON [PRIMARY]
GO

Java:

@Table(name = "PAYMENT_RECORD_T")
@Entity
public class PaymentRecordT {
    ...
    @ManyToOne
    @PrimaryKeyJoinColumn(name = "payment_status_cd", referencedColumnName = "REC_STAT_CD")
    private RecordStatusT recordStatusT;
}

@Table(name = "RECORD_STATUS_T")
@Entity
public class RecordStatusT {

  @Column(name = "REC_STAT_CD")
  @Id
  private String recStatCd;

  @Column(name = "REC_STAT_DSC")
  @Basic
  private String recStatDsc;
}

Others relations in our app might not be primary key relations but loose relations in which case its just @JoinColumn but the pattern would be the same.

My 'weirdness' is the following:

So in this example I have a list of 10 'Payment Records' each of them have such a record status, which is actually NON NULL in the database. When I do the initial retrieval via EJB method it grabs the 10 records and I also get the correctly resolved/queried record statuses. Then I add a new record via EJB method (TRANSACTION_REQUIERD). After the add method returns I can query the new payment record in the database via SSMS. Its committed and it looks 100% correct and it contains a correct record status code.

Now I run the retrieval method again and I get the 11 records as I would expect. Only the 11th (newly inserted) record will have recordStatusT as null. When I restart the app all goes well again for the retrieval of all 11 records. But for subsequent additions the outcome seems again 'undefined'.

In JDBC logging I an see that during the original retrieval of the records the record_status_t table was queried but the 2nd time around it was not and I have no explanation why.

I played with FETCHTYPE.EAGER and read up on caching etc but I'm not going anywhere.

Any ideas?

Thanks for your time

Carsten

1

There are 1 best solutions below

0
CalleWirsch On

I solved the problem by ensuring that after inserts/updates the objects arent being queried from the cache. In the end - rather than doing it with query hint - I disabled caching for the entity involved using the @Chacheable annotation, like so

@Table(name = "PAYMENT_RECORD_T")
@Entity
@Cacheable(false)
public class PaymentRecordT {
    ...
    @ManyToOne
    @PrimaryKeyJoinColumn(name = "payment_status_cd", referencedColumnName = "REC_STAT_CD")
    private RecordStatusT recordStatusT;
}

I still feel like there should be a better solution. Eclipselink tracks the inserts/updates so it should be able track what needs rereading from the DB and what not. I still feel like I don't fully understand the entire picture, but this works for me and its reasonably clean.

I can leave the considerable amount of read-only data/objects chacheable and the few that are changeable as non-cacheable.

Thanks for reading

Carsten