users@glassfish.java.net

Lob field issues after redeploy of EAR (MySQL/TopLink/EJB3/ArrayList/Lob)

From: <glassfish_at_javadesktop.org>
Date: Tue, 18 Nov 2008 07:55:51 PST

Having an issue with Glassfish/Toplink/Mysql/EJB3. I have an EJB3 Entity that contains a field like this:

    @Lob
    @Basic(fetch = FetchType.EAGER, optional = false)
    private ArrayList<TaskDependency> taskDependencyList = new ArrayList<TaskDependency>();

The TaskDependency object is Serializable and contains two Longs and a boolean. I've had no problems with this field until recently when I noticed that after a redeploy of my EAR file, when I access an existing entity, this field always returns a zero length arraylist. I've been developing with a Table Generation Strategy of Drop and Create and recently changed to just CREATE, that is when I noticed the issue.

I'm using the following glassfish (version returned by version button in admin app): Sun Java System Application Server 9.1_02 (build b04-fcs)

I'm using the toplink that was installed with GF.

I'm using MySQL5

I can see that the binary serialization of the ArrayList is in the database, but after a redeploy, it seems that TopLink can't read it back out.

I tried adding the following to the EJB field:
@Column(columnDefinition = "MEDIUMBLOB")

but that didn't make any difference. I tried a table generation strategy of NONE but that didn't help. This field returns correct data after the initial EAR deploy but after a redeploy, this field is always an empty list for any existing data. Interestingly, any new data that is created after the redeploy can be read back correctly. It's just the existing data that is messed up.

Does anyone have any ideas how to fix this?


Note: I had a similar problem a while back with a large String field in an entity. When I redeployed the EAR file all the existing String fields would read back double their actual length and the unicode bytes were interpreted directly as characters. To fix the issue I had to include a mysql specific field type to force it to a MEDIUMTEXT field since it appeared that TopLink was interpreting the orignal field as a BLOB mysql type and not a TEXT mysql type.
[Message sent by forum member 'sebswift' (sebswift)]

http://forums.java.net/jive/thread.jspa?messageID=317239