Heap Exhaustion Exception for One-to-One Unidirectional

Question

Using Glassfish 2.1 with TopLink, EJB3 and JPA in WinXP SP2 environment. Am observing heap exhaustion exceptions apparently whenever an entity references a different entity via a one-to-one unidirectional relation.
Have resolved two heap exhaustion exception problems but have one more remaining.
The first heap exhaustion problem occurred when entity "A" declared a one-to-many relationship with entity "B", and entity "B" declared a many-to-one relationship with entity "A". But entity "A" also erroneously declared a one-to-one unidirectional relationship with entity "B". As soon as entity "A" had an entity "B" inserted into it, a heap exhaustion exception occurred when entity "A" was serialized in a return statement. As soon as the erroneous one-to-one unidirectional relationship was removed from entity "A", the heap exhaustion exceptions ceased.
The second heap exhaustion problem occurred when the same entity "A" mistakenly declared a one-to-one unidirectional relationship with entity "C", and entity "C" correctly declared a many-to-one relationship with entity "A". Once again as soon as entity "A" had an entity "C" inserted into it, a heap exhaustion exception occurred when entity "A" was serialized in a return statement. As soon as the erroneous one-to-one was corrected to a one-to-many, the heap exhaustion exceptions ceased.
But the third heap exhaustion problem occurs when the same entity "A" correctly declares a one-to-one unidirectional relationship with entity "D". As soon as entity "A" has an entity "D" inserted into it, a heap exhaustion exception occurs when entity "A" is serialized in a return statement. I cannot "fix" this as I did in the two above cases because this time the one-to-one unidirectional relationship is correct.
Have one-to-one bidirectional relationships as well as one-to-many / many-to-one that do not trigger heap exhaustion exceptions when serialized in a return statement.
Here is the Java code that declares the problem one-to-one bidirectional relationship in entity "A":
@OneToOne(cascade={CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH }, optional=true, fetch=FetchType.LAZY)
@JoinColumn(name="fk_asset_type_id", referencedColumnName="asset_type_id", updatable=false)
public AssetType getAssetType() {
return this.assetType;
public void setAssetType(AssetType assetType) {
this.assetType = assetType;
Here is the SQL used to generate the table associated with entities "D" and "A":
CREATE TABLE [dbo].[asset_type](
     [asset_type_id] [numeric](18, 0) IDENTITY(1,1) NOT NULL,
     [asset_name] [varchar](40) NULL,
     [asset_description] [varchar](50) NULL,
     [last_user] [varchar](50) NULL,
     [last_mod] [timestamp] NOT NULL,
CONSTRAINT [PK_asset_type] PRIMARY KEY CLUSTERED
([asset_type_id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY]
GO
CREATE TABLE [dbo].[server_asset](
     [server_asset_id] [numeric](18, 0) IDENTITY(1,1) NOT NULL,
     [nsn] [varchar](40) NULL,
     [gov_furnish_equip_asset_id] [varchar](255) NULL,
     [server_name] [varchar](255) NULL,
     [server_ip_addr] [varchar](255) NULL,
     [serial_nbr] [varchar](50) NULL,
     [outfitting_list] [text] NULL,
     [update_cst] [varchar](255) NULL,
     [update_pst] [varchar](255) NULL,
     [date_decommissioned] [datetime] NULL,
     [server_asset_org_date] [datetime] NULL,
     [server_asset_update_date] [datetime] NULL,
     [fk_manufacturer_id] [numeric](18, 0) NULL,
     [fk_trade_partner_id] [numeric](18, 0) NULL,
     [fk_asset_type_id] [numeric](18, 0) NULL,
     [fk_model_id] [numeric](18, 0) NULL,
     [fk_item_part_id] [numeric](18, 0) NULL,
     [fk_gold_disk_asset_id] [numeric](18, 0) NULL,
     [fk_jtdi_location_id] [numeric](18, 0) NULL,
     [last_user] [varchar](50) NULL,
     [last_mod] [timestamp] NOT NULL,
CONSTRAINT [PK_server_asset] PRIMARY KEY CLUSTERED
([server_asset_id] ASC)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[server_asset] WITH CHECK ADD CONSTRAINT [FK_server_asset_asset_type] FOREIGN KEY([fk_asset_type_id])
REFERENCES [dbo].[asset_type] ([asset_type_id])
GO
Have been batting this issue around on the Manning Panda forum. Consensus there is that the problem may be TopLink related. Would be most grateful for any suggestions. The easy way out would be to change the one-to-one unidirectional to bidirectional but don't want to do that unless there is no alternative. Thanks.

Answer 1

Looking at the stack trace (found in your post on the GlassFish forum) it appears to be an issue with corba serialization in the container. I found this bug, https://glassfish.dev.java.net/issues/show_bug.cgi?id=2693 in which the stack looks almost identical to yours.
The only way that I think TopLink could be involved is that TopLink is weaving your code, and potentially so is corba. You can try turning off weaving to see if that 'solves' your problem. (Note: I am not confidant that this will work, but I notice that the corba stack may be doing some weaving of it's own.)
The persistence unit property is toplink.weaving. Setting it to false will turn off TopLink weaving.
<property name="toplink.weaving" value="false"/>