users@glassfish.java.net

Re: Heap Exhaustion Exception for One-to-One Unidirectional

From: Mitesh Meswani <Mitesh.Meswani_at_Sun.COM>
Date: Tue, 08 Apr 2008 17:19:16 -0700

Can you please post stack trace when this happens.

glassfish_at_javadesktop.org wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>