Sandeep Vaid

Ranch Hand
+ Follow
since Feb 27, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Sandeep Vaid

So in the object diagram, current action will be directly under value stack instead of context map. Right?
and where can i see the object hierarchy?
9 years ago
As per my knowledge, the current action object is directly under value stack (and value stack is the root object of the contextmap) but diagram in this link https://struts.apache.org/docs/ognl.html shows the current action is directly under context map (instead of value stack). which is true?
9 years ago

I using Weblogic 8.1 sp4, Db2/NT 8.2.9, JDK 1.4,JDBC in multithreaded environment
When i issue resultset.next(), sometimes (very few times that too when number of units of processing is a bit high) it give me the following error:

java.sql.SQLException: [BEA][DB2 JDBC Driver][DB2]Abnormal end unit of work condition occurred.
at weblogic.jdbc.base.BaseExceptions.createException(Ljava.lang.String;Ljava.lang.String;I)Ljava.sql.SQLException;(Unknown Source)
at weblogic.jdbc.base.BaseExceptions.getException(I[Ljava.lang.String;Ljava.lang.String;I)Ljava.sql.SQLException;(Unknown Source)
at weblogic.jdbc.db2.drda.DRDARequest.processSQLCA(Lweblogic.jdbc.base.BaseWarnings;)V(Optimized Method)
at weblogic.jdbc.db2.drda.DRDARequest.processCodePoint(IILweblogic.jdbc.base.BaseWarnings;)Z(Optimized Method)
at weblogic.jdbc.db2.drda.DRDAStatementRequest.processCodePoint(IILweblogic.jdbc.base.BaseWarnings;)Z(Optimized Method)
at weblogic.jdbc.db2.drda.DRDAResultSetRequest.processCodePoint(IILweblogic.jdbc.base.BaseWarnings;)Z(Optimized Method)
at weblogic.jdbc.db2.drda.DRDARequest.processReply(Lweblogic.jdbc.base.BaseWarnings;)V(Optimized Method)
at weblogic.jdbc.db2.drda.DRDARequest.ensureBytes(ILweblogic.jdbc.base.BaseWarnings;)V(Optimized Method)
at weblogic.jdbc.db2.drda.DRDARequest.processSQLCA(Lweblogic.jdbc.base.BaseWarnings;)V(Optimized Method)
at weblogic.jdbc.db2.drda.DRDAResultSetRequest.getNextRow(Lweblogic.jdbc.base.BaseWarnings;)Z(Optimized Method)
at weblogic.jdbc.db2.DB2ImplResultSet.fetchAtPosition(I)Z(Optimized Method)
at weblogic.jdbc.base.BaseImplResultSet.next()Z(Optimized Method)
at weblogic.jdbc.base.BaseResultSet.next()Z(Optimized Method)
at weblogic.jdbc.wrapper.ResultSet_weblogic_jdbc_base_BaseResultSet.next()Z(Optimized Method)

Please let me know the solution to this problem..
14 years ago
You have written discriminator column to be type INTEGER and in subclass you are passing "0" (String)... This seems incorrect..
Few Queries:

1) What is this Type function??
2) You mentioned about discriminator column... Where is the inheritance coming into picture..
You mentioned SubEntity and BaseEntity. Does this means you are using inheritance.. If yes, then out of 3, which inheritance strategy you are using??
It looks like something is wrong with the inheritance ORM mapping...

Please post your inheritance ORM mapping..
What i really want to ask is :

Entitymanager - If the flush mode is set to COMMIT, the persistence provider will only synchronize with the database when the transaction commits


Query - If the Query is set to FlushModeType.COMMIT, the effect of updates made to entities in the persistence context is not defined by the JPA specification...

So why this different behaviour in JPA specs ?

[P-331 of EJB3 In Action Book] states:
"By default, the database flush mode is set to AUTO. This means that the Entity-Manager performs a flush operation automatically as needed.
In general, this occurs at the end of a transaction for transaction-scoped EntityManagers and when the persistence context is closed for
application-managed or extendedscope EntityManagers. In addition, if entities with pending changes are used in a query, the persistence
provider will flush changes to the database before executing the query.If the flush mode is set to COMMIT, the persistence provider will
only synchronize with the database when the transaction commits.However, you should be careful with this, as it will be your responsibility
to synchronize entity state with the database before executing a query. If you don’t do this and an EntityManager query returns stale
entities from the database, the application can wind up in an inconsistent state."

[P-353 EJB3 In Action Book] states:
"If the Query is set to FlushModeType.COMMIT, the effect of updates made to entities in the persistence context is not defined
by the specification, and the actual behavior is implementation specific".

So setting the flush mode as COMMIT on EntityManager and Query have different results..Right ??
The mikalai Zaikin Notes States
"A class is permitted to override an inherited callback method of the same callback type, and in this case, the overridden method is NOT invoked."
However in the example given, the overriden method is invoked...
@Entity
public class Animal {
....
@PostPersist
protected void postPersistAnimal() {
System.out.println("Inside Animal.postPersistAnimal()");
}
}

@Entity
@EntityListeners({CatListener.class, CatListener2.class})
public class Cat extends Pet {
...
}

@EntityListeners(SiameseCatListener.class)
@Entity
public class SiameseCat extends Cat {
...
@PostPersist
protected void postPersistAnimal() {
System.out.println("Inside SiameseCat.postPersistAnimal()");
}
}

Here the overridden method SiameseCat.postPersistAnimal() is called and Animal.postPersistAnimal() is not at all called.
[P-298 Of EJB3 In Action Book] States: In the diagram, it shows that using a refresh method a detatched entity can become managed..
[P-332Of EJB3 In Action Book] States: The refresh method only works on managed entities...
Aren;t the above 2 statements contradictory? Moreover Statement1 is incorrect...

Mikalai Zaikin Notes says
"If an entity manager with transaction-scoped persistence context is in use, the resulting
entities will be DETACHED; if an entity manager with an extended persistence context is used,
they will be MANAGED."

Is it a typo "is in use'? Does it wants to says when transaction ends, with transaction-scoped persistence context - the resulting
entities will be DETACHED While if an entity manager with an extended persistence context is used, they will be MANAGED..
[P-298 Of EJB3 In Action Book] States: In the diagram, it shows that using a refresh method a detatched entity can become managed..
[P-332Of EJB3 In Action Book] States: The refresh method only works on managed entities...
Aren;t the above 2 statements contradictory? Moreover Statement1 is incorrect...

In application-managed EntityManager, we explicitly call entityManager.joinTransaction().
In container-manager Entitymanager does it automaticalls joins JTA ?
Moreover at P-298, the diagram shows refresh() method working on detatched entity... Is that an errata ?
P-331 says : "We use the method to undo changes made by the ItemManager client and return fresh entity data from the database."
but when we call merge() (before refresh()), the changes made by the client will get reflected in the database.