Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] OneToOne AND ManyToOne Mapping works with FetchType.EAGER but not with FetchType.LAZY -> Exception when deploying (SGES 2.1)

"When you say "The application did never deploy", do you mean you cannot get
the 
application to deploy at all?  (i.e. There is no set of mappings that allow
the 
application to deploy.)  In that case, the issue with LAZY is likely just a
side 
effect of something greater."

I can deploy the application. But I have to change approximately 20
OneToOne/ManyToOne mappings from FetchType.LAZY to FetchType.EAGER. If only
one of those 20 mappings has defined FetchType.LAZY the application does not
deploy.

"If there is a way you can successfully deploy the 
application, ideally, you could identify one mapping that when changed from 
EAGER to LAZY causes the failure and post how that mapping is defined."

I cannot identify one mapping that when changed from EAGER to LAZY causes
the failure. I have tested every single of these 20 mappings separately by
changing the FetchType to LAZY. But the application did not deploy. In other
words, all these 20 mappings require FetchType.EAGER to deploy the
application. If only one of those mappings has declared FetchType.LAZY the
application does not deploy. For every single of those 20 mappings that have
declared FetchType.LAZY instead of EAGER I get the exceptions that I have
shown in my previous postings. 

Note: Besides these OneToOne/ManyToOne 20 mappings that absolutely require
FetchType.EAGER to successfully deploy the application without any
exceptions there are approximately 10 OneToOne/ManyToOne mappings left that
have defined FetchType.LAZY. For these 10 mappings I do not have to change
the FetchType to EAGER to deploy the application successfully and without
any exceptions.

Please remember: Originally, every OneToOne/ManyToOne mapping in my
application had declared FetchType.LAZY and it deployed fine on SJSAS 9.1
Update 2. But since I switched to SGES 2.1 I get this odd behavior described
above. EclipseLink version was and is 1.0.2. So (I think) it must have
something to do with SGES 2.1.


"- I assume "[...]" is not the actual value for mappedby"
That is true. It is always the same schema: the name of the entity in
lowercase letters without any special characters.

"- Include the cooresponding variable declarations"
The schema is also always the same. It is "private EntityClass name;".
Example: "private User user;"

"- If you are using PROPERTY access, include the cooresponding getter/setter 
declarations"
These getters and setters are all "standard" getters/setters as NetBeans
creates them without any additional business logic.

"- Include the class declaration along with any annotations on the class 
declaration for all mappings you include"
I would have to post my whole ERM (lots of code). I do not think it will be
helpful. Besides, all my entity classes have almost the same schema and the
same annotations. Here is an example of class "User":

@Entity
@Table(name = "users")
@TableGenerator(table = "_pk_generators", pkColumnName = "_pk",
valueColumnName = "value", name = "user", initialValue = 1000,
allocationSize = 100)
@Cache(type=CacheType.FULL, size = 10000)
public class User implements Serializable, Comparable<User> {

	@Id
	@GeneratedValue(strategy = GenerationType.TABLE, generator = "user")
	@Column(name = "_id", nullable = false, updatable = false)
	private long id;
	@Version
	private int version;
        //... some columns here
        //... some mappings here
        //... constructor
        //... "standard" getters/setters 
        //... overridden methods equals(...), hashCode(), compareTo(...)
}

-----

Currently I am little bit short of time, but I will investigate further.
-- 
View this message in context: http://www.nabble.com/OneToOne-Mapping-works-with-FetchType.EAGER-but-not-with-FetchType.LAZY--%3E-Exception-when-deploying-%28SGES-2.1%29-tp21711849p21776510.html
Sent from the EclipseLink - Users mailing list archive at Nabble.com.



Back to the top