ID field auto generation issue for multiple databases supporting
Hello, I found If I user derby, I need to use @GeneratedValue(strategy=GenerationType.IDENTITY) for ID field. And for oracle database, I need to use @GeneratedValue(strategy=GenerationType.SEQUENCE). The question is if I want to use same entity classes to support both derby and oracle, how should I do? Do we have best practice for ID field value generation strategy for multiple databases supporting? Regards, Yu Wang
[ANNOUNCE] OpenJPA Logo Contest
Announcing the OpenJPA Logo Contest! Submissions: Accepted now through June 30, 2009 Rules and Guidelines: See the Logo Contest page [1] for more details. Voting: Will occur from July 1 through July 14. Winner: Will be announced on or after July 15. [1] http://cwiki.apache.org/openjpa/logo-contest.html -Donald
Use getters/setters only
I seem to remember somewhere reading that one should use getters and setters only when accessing persistent fields. This seems obvious from outside the entity class, but not so obvious from inside. Can anyone point me to the manual or other resource that describes this or explain it here? Thanks. -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
Bad value for type BigDecimal : Y
Hi All, I am using apache geronimo v2.1.4 which is bundled with openJPA 1.2.1 and postgresql 8.5.3. while running an applicaiton which is based on JSF and EJB's I get the following error. 2009-06-11 16:19:58,417 TRACE [Runtime] An exception occurred while ending the transaction. This exception will be re-thrown. openjpa-1.0.3-r420667:677674 nonfatal store error org.apache.openjpa.util.StoreException: Bad value for type BigDecimal : Y at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3951) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:491) at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116) at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78) at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2886) at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2964) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1586) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3844) at org.apache.openjpa.kernel.StateManagerImpl.setPCState(StateManagerImpl.java:207) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1546) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.getTransactionalStates(BrokerImpl.java:3729) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1872) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:472) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:258) at org.apache.openejb.core.transaction.TransactionPolicy.rollbackTransaction(TransactionPolicy.java:183) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:78) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy21.findByInsAndType(Unknown Source) at com.tnhsp.mbeans.biomedicalwaste.wasteDetailsMBean.getStockingpointList(wasteDetailsMBean.java:1658) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at javax.el.BeanELResolver.getValue(BeanELResolver.java:62) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:104) at org.apache.el.parser.AstValue.getValue(AstValue.java:118) at
Re: Bad value for type BigDecimal : Y
Can you provide more details on the Stockingpoint entity being used, like the orm.xml or annotations? -Donald Ashish Jain wrote: Hi All, I am using apache geronimo v2.1.4 which is bundled with openJPA 1.2.1 and postgresql 8.5.3. while running an applicaiton which is based on JSF and EJB's I get the following error. 2009-06-11 16:19:58,417 TRACE [Runtime] An exception occurred while ending the transaction. This exception will be re-thrown. openjpa-1.0.3-r420667:677674 nonfatal store error org.apache.openjpa.util.StoreException: Bad value for type BigDecimal : Y at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3951) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:491) at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116) at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78) at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2886) at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2964) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1586) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3844) at org.apache.openjpa.kernel.StateManagerImpl.setPCState(StateManagerImpl.java:207) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1546) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.getTransactionalStates(BrokerImpl.java:3729) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1872) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:472) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:258) at org.apache.openejb.core.transaction.TransactionPolicy.rollbackTransaction(TransactionPolicy.java:183) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:78) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy21.findByInsAndType(Unknown Source) at com.tnhsp.mbeans.biomedicalwaste.wasteDetailsMBean.getStockingpointList(wasteDetailsMBean.java:1658) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at javax.el.BeanELResolver.getValue(BeanELResolver.java:62) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.access$301(FacesCompositeELResolver.java:46) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver$4.invoke(FacesCompositeELResolver.java:108) at org.apache.myfaces.el.unified.resolver.FacesCompositeELResolver.invoke(FacesCompositeELResolver.java:148) at
Strange behavior with a distributed transaction
Hi,
I have a scenario where I'm trying to run a distributed transaction across
two websphere 6.1 app servers on two different nodes (2 physical machines).
A stateless session bean on server 1 makes an entry to a table in the
database after which it calls the remote ejb on server 2 which again makes
an entry on the same table in the same database.
On server 1
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class ManagerBean implements Manager {
@PersistenceContext(unitName=bs)
EntityManager manager;
public void saveAgreement() {
//snip...get the context etc
try {
SEPAgreement agreement = new SEPAgreement(786l); //the entity
object
manager.persist(agreement);
MyRemote remote = (MyRemote) PortableRemoteObject.narrow(
ctx.lookup(dk.pbs.bs.functions.MyRemote),
MyRemote.class);
System.out.println(Cast successful);
agreement = new SEPAgreement(7864l);
remote.insert(agreement);
System.out.println(First call complete);
SEPAgreement agr1= manager.find(SEPAgreement.class, 786);
System.out.println(Found first + agr1);
SEPAgreement agr2 = manager.find(SEPAgreement.class, 7864);
System.out.println(Found second + agr2);
} catch (Exception e) {
//snip
On server 2:
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MyRemoteImpl implements MyRemote {
@PersistenceContext(unitName=abc)
EntityManager manager;
public void insert(SEPAgreement agreement) {
System.out.println(In remote);
System.out.println(Before persist + agreement);
try {
manager.persist(agreement);
manager.flush();
System.out.println(After persist + agreement);
} catch (Exception e) {
//snip
In the output on server 1 it prints:
Cast successful
first call complete
found first SEP786
It then hangs until the transaction on the second server times out (for some
strange reason)
In the output on server 2 it prints:
Before persist 7864
After persist 7864
waits...for 60 seconds after which it gives a transaction time out message.
The thing is that the second call to manager.find() for an object which is
persisted in the remote call causes it to hang. If I comment out the call
everything works fine. Also the noticeable thing is that after the second
server gives a time out message for the transaction, I then see the
remaining sysouts
i.e
Found second SEPnull
I am wondering if I'm missing something here. Although I'm not sure if the
second find should have succeeded given that I'm not using a any sort of
distributed cache yet, I don't expect it to hang either. Any ideas? Find the
code attached.
http://n2.nabble.com/file/n3063290/strangebehaviourwithadistributedtransaction_.zip
strangebehaviourwithadistributedtransaction_.zip
--
View this message in context:
http://n2.nabble.com/Strange-behavior-with-a-distributed-transaction-tp3063290p3063290.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Need to list embeddable classes in persistence.xml?
Hello. I've found that OpenJPA needs me to list my @Embeddable classes in persistence.xml as well as my @Entity classes. This is not needed by Hibernate or EclipseLink. I couldn't find a relevant section of the specification that addresses this. Is this a bug or just a minor annoyance? I'm trying to code for maximum portability between at least these three persistence providers and so want to know where the edge cases are. I'm using OpenJPA-1.3.0-SNAPSHOT from the Apache snapshots Maven repository. Thanks, Laird
Re: Use getters/setters only
This section of the OpenJPA manual describes this: http://openjpa.apache.org/builds/1.2.1/apache-openjpa-1.2.1/docs/manual/manual.html#jpa_overview_meta_field The major point it makes is this: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly. Other methods, including internal business methods in the persistent class, should go through the getter and setter methods when manipulating persistent state. Also, take care when adding business logic to your getter and setter methods. Consider that they are invoked by the persistence implementation to load and retrieve all persistent state; other side effects might not be desirable. The reason this point is stressed is that when using property access, calling the getter and setter end up calling the enhanced versions of these that OpenJPA creates during the bytecode enhancement. For example, when you call a setter, OpenJPA will know to mark that field as dirty. When you call the getter, OpenJPA may end up loading the relevant data from the DB (for example on first access of a lazily loaded field within a transaction). If you were accessing the field directly, OpenJPA won't know about it - so in the above examples it may not mark the field as dirty or access the DB to load the lazily loaded field value. Note that none of this is relevant if you are using field access rather than property access. Daryl Stultz wrote: I seem to remember somewhere reading that one should use getters and setters only when accessing persistent fields. This seems obvious from outside the entity class, but not so obvious from inside. Can anyone point me to the manual or other resource that describes this or explain it here? -- View this message in context: http://n2.nabble.com/Use-getters-setters-only-tp3062448p3063648.html Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Strange behavior with a distributed transaction
Sounds like DB2 is getting an exclusive lock on the row when you do the
first find. WebSphere's default isolation level is RR which will obtain long
lived locks.
Unfortunately it isn't always easy to change the default in WebSphere. The
recommended way is to create a resource reference in your application, set
the isolation level on the resource ref, and update persistence.xml to use
it (ie jta-data-sourcejava:comp/env/myDataSource/jta-data-source). This
approach can be a lot of work if you have a lot of persistence units..
Another way to go is to change the default level on the WAS datasource. This
has the downside of affecting everyone who uses the datasource though. To do
this add at custom property as described here [1].
Either way you probably want to set the isolation to the JPA default of
ReadCommitted.
[1] http://www-01.ibm.com/support/docview.wss?rs=180uid=swg21224492
Hope this helps,
-mike
On Thu, Jun 11, 2009 at 12:11 PM, devu213 devusm...@gmail.com wrote:
Hi,
I have a scenario where I'm trying to run a distributed transaction across
two websphere 6.1 app servers on two different nodes (2 physical machines).
A stateless session bean on server 1 makes an entry to a table in the
database after which it calls the remote ejb on server 2 which again makes
an entry on the same table in the same database.
On server 1
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class ManagerBean implements Manager {
@PersistenceContext(unitName=bs)
EntityManager manager;
public void saveAgreement() {
//snip...get the context etc
try {
SEPAgreement agreement = new SEPAgreement(786l); //the
entity object
manager.persist(agreement);
MyRemote remote = (MyRemote) PortableRemoteObject.narrow(
ctx.lookup(dk.pbs.bs.functions.MyRemote),
MyRemote.class);
System.out.println(Cast successful);
agreement = new SEPAgreement(7864l);
remote.insert(agreement);
System.out.println(First call complete);
SEPAgreement agr1= manager.find(SEPAgreement.class, 786);
System.out.println(Found first + agr1);
SEPAgreement agr2 = manager.find(SEPAgreement.class, 7864);
System.out.println(Found second + agr2);
} catch (Exception e) {
//snip
On server 2:
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MyRemoteImpl implements MyRemote {
@PersistenceContext(unitName=abc)
EntityManager manager;
public void insert(SEPAgreement agreement) {
System.out.println(In remote);
System.out.println(Before persist + agreement);
try {
manager.persist(agreement);
manager.flush();
System.out.println(After persist + agreement);
} catch (Exception e) {
//snip
In the output on server 1 it prints:
Cast successful
first call complete
found first SEP786
It then hangs until the transaction on the second server times out (for
some
strange reason)
In the output on server 2 it prints:
Before persist 7864
After persist 7864
waits...for 60 seconds after which it gives a transaction time out message.
The thing is that the second call to manager.find() for an object which is
persisted in the remote call causes it to hang. If I comment out the call
everything works fine. Also the noticeable thing is that after the second
server gives a time out message for the transaction, I then see the
remaining sysouts
i.e
Found second SEPnull
I am wondering if I'm missing something here. Although I'm not sure if the
second find should have succeeded given that I'm not using a any sort of
distributed cache yet, I don't expect it to hang either. Any ideas? Find
the
code attached.
http://n2.nabble.com/file/n3063290/strangebehaviourwithadistributedtransaction_.zip
strangebehaviourwithadistributedtransaction_.zip
--
View this message in context:
http://n2.nabble.com/Strange-behavior-with-a-distributed-transaction-tp3063290p3063290.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Use getters/setters only
On Thu, Jun 11, 2009 at 2:20 PM, Simon Droscher simon.drosc...@elasticpath.com wrote: The major point it makes is this: When using property access, only the getter and setter method for a property should ever access the underlying persistent field directly That's exactly what I was looking for, thanks. Note that none of this is relevant if you are using field access rather than property access. But I didn't expect that! (from the manual) To use field access for an entity using annotation metadata, simply place your metadata and mapping annotations on your field declarations: I am using field access. I placed my annotations on the fields simply because I like them there. I didn't realize there was a functional difference. Is there any advantage/disadvantage to field vs property access? It seems property access has the potential gotcha, while field does not. Perhaps there is some other cost... -- Daryl Stultz _ 6 Degrees Software and Consulting, Inc. http://www.6degrees.com mailto:da...@6degrees.com
Re: Strange behavior with a distributed transaction
Thanks Michael. However, I forgot to mention this:
I also tried swapping the two find calls i.e do a find for the entity
persisted on the remote server first and then try and do a find for the
entity on the local server. This time it hangs on the first call itself i.e
the output now is:
On server 1
Cast successful
First call complete
Hang...until 60 sec
Found FirstSEPnull
Found SecondSEP784
Do you think it is still an isolation level problem?
I will try having only a single find for the entity persisted on the remote
server and let you know the results.
Michael Dick wrote:
Sounds like DB2 is getting an exclusive lock on the row when you do the
first find. WebSphere's default isolation level is RR which will obtain
long
lived locks.
Unfortunately it isn't always easy to change the default in WebSphere. The
recommended way is to create a resource reference in your application, set
the isolation level on the resource ref, and update persistence.xml to use
it (ie jta-data-sourcejava:comp/env/myDataSource/jta-data-source).
This
approach can be a lot of work if you have a lot of persistence units..
Another way to go is to change the default level on the WAS datasource.
This
has the downside of affecting everyone who uses the datasource though. To
do
this add at custom property as described here [1].
Either way you probably want to set the isolation to the JPA default of
ReadCommitted.
[1] http://www-01.ibm.com/support/docview.wss?rs=180uid=swg21224492
Hope this helps,
-mike
On Thu, Jun 11, 2009 at 12:11 PM, devu213 devusm...@gmail.com wrote:
Hi,
I have a scenario where I'm trying to run a distributed transaction
across
two websphere 6.1 app servers on two different nodes (2 physical
machines).
A stateless session bean on server 1 makes an entry to a table in the
database after which it calls the remote ejb on server 2 which again
makes
an entry on the same table in the same database.
On server 1
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class ManagerBean implements Manager {
@PersistenceContext(unitName=bs)
EntityManager manager;
public void saveAgreement() {
//snip...get the context etc
try {
SEPAgreement agreement = new SEPAgreement(786l); //the
entity object
manager.persist(agreement);
MyRemote remote = (MyRemote) PortableRemoteObject.narrow(
ctx.lookup(dk.pbs.bs.functions.MyRemote),
MyRemote.class);
System.out.println(Cast successful);
agreement = new SEPAgreement(7864l);
remote.insert(agreement);
System.out.println(First call complete);
SEPAgreement agr1= manager.find(SEPAgreement.class, 786);
System.out.println(Found first + agr1);
SEPAgreement agr2 = manager.find(SEPAgreement.class,
7864);
System.out.println(Found second + agr2);
} catch (Exception e) {
//snip
On server 2:
@Stateless
@TransactionManagement(TransactionManagementType.CONTAINER)
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class MyRemoteImpl implements MyRemote {
@PersistenceContext(unitName=abc)
EntityManager manager;
public void insert(SEPAgreement agreement) {
System.out.println(In remote);
System.out.println(Before persist + agreement);
try {
manager.persist(agreement);
manager.flush();
System.out.println(After persist + agreement);
} catch (Exception e) {
//snip
In the output on server 1 it prints:
Cast successful
first call complete
found first SEP786
It then hangs until the transaction on the second server times out (for
some
strange reason)
In the output on server 2 it prints:
Before persist 7864
After persist 7864
waits...for 60 seconds after which it gives a transaction time out
message.
The thing is that the second call to manager.find() for an object which
is
persisted in the remote call causes it to hang. If I comment out the call
everything works fine. Also the noticeable thing is that after the second
server gives a time out message for the transaction, I then see the
remaining sysouts
i.e
Found second SEPnull
I am wondering if I'm missing something here. Although I'm not sure if
the
second find should have succeeded given that I'm not using a any sort of
distributed cache yet, I don't expect it to hang either. Any ideas? Find
the
code attached.
http://n2.nabble.com/file/n3063290/strangebehaviourwithadistributedtransaction_.zip
strangebehaviourwithadistributedtransaction_.zip
--
View this message in
Re: Bad value for type BigDecimal : Y
Hi Donald, There is no associated orm.xml in the applicaiton.Annotations in Stockingpoint entity are @Table, @NamedQueries, @ManyToOne @JoinColumn, @Temporal Thanks Ashish On Thu, Jun 11, 2009 at 10:26 PM, Donald Woods dwo...@apache.org wrote: Can you provide more details on the Stockingpoint entity being used, like the orm.xml or annotations? -Donald Ashish Jain wrote: Hi All, I am using apache geronimo v2.1.4 which is bundled with openJPA 1.2.1 and postgresql 8.5.3. while running an applicaiton which is based on JSF and EJB's I get the following error. 2009-06-11 16:19:58,417 TRACE [Runtime] An exception occurred while ending the transaction. This exception will be re-thrown. openjpa-1.0.3-r420667:677674 nonfatal store error org.apache.openjpa.util.StoreException: Bad value for type BigDecimal : Y at org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:3951) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:97) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:83) at org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:59) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:491) at org.apache.openjpa.kernel.DelegatingStoreManager.load(DelegatingStoreManager.java:116) at org.apache.openjpa.kernel.ROPStoreManager.load(ROPStoreManager.java:78) at org.apache.openjpa.kernel.StateManagerImpl.loadFields(StateManagerImpl.java:2886) at org.apache.openjpa.kernel.StateManagerImpl.loadField(StateManagerImpl.java:2964) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1586) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.setDirty(BrokerImpl.java:3844) at org.apache.openjpa.kernel.StateManagerImpl.setPCState(StateManagerImpl.java:207) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1546) at org.apache.openjpa.kernel.StateManagerImpl.dirty(StateManagerImpl.java:1485) at org.apache.openjpa.kernel.StateManagerImpl.dirtyCheck(StateManagerImpl.java:808) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.dirtyCheck(BrokerImpl.java:4621) at org.apache.openjpa.kernel.BrokerImpl$ManagedCache.access$000(BrokerImpl.java:4361) at org.apache.openjpa.kernel.BrokerImpl.hasTransactionalObjects(BrokerImpl.java:3740) at org.apache.openjpa.kernel.BrokerImpl.getTransactionalStates(BrokerImpl.java:3729) at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1872) at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1853) at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1771) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:514) at org.apache.geronimo.transaction.manager.TransactionImpl.beforeCompletion(TransactionImpl.java:499) at org.apache.geronimo.transaction.manager.TransactionImpl.rollback(TransactionImpl.java:472) at org.apache.geronimo.transaction.manager.TransactionManagerImpl.rollback(TransactionManagerImpl.java:258) at org.apache.openejb.core.transaction.TransactionPolicy.rollbackTransaction(TransactionPolicy.java:183) at org.apache.openejb.core.transaction.TxRequired.afterInvoke(TxRequired.java:78) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:233) at org.apache.openejb.core.stateless.StatelessContainer._invoke(StatelessContainer.java:188) at org.apache.openejb.core.stateless.StatelessContainer.invoke(StatelessContainer.java:165) at org.apache.openejb.core.ivm.EjbObjectProxyHandler.businessMethod(EjbObjectProxyHandler.java:217) at org.apache.openejb.core.ivm.EjbObjectProxyHandler._invoke(EjbObjectProxyHandler.java:77) at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245) at org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49) at $Proxy21.findByInsAndType(Unknown Source) at com.tnhsp.mbeans.biomedicalwaste.wasteDetailsMBean.getStockingpointList(wasteDetailsMBean.java:1658) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:45) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at java.lang.reflect.Method.invoke(Method.java:599) at javax.el.BeanELResolver.getValue(BeanELResolver.java:62) at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:53) at
