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 and/or Glassfish 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.
[Message sent by forum member 'franknatoli' (franknatoli)]
http://forums.java.net/jive/thread.jspa?messageID=268265