You should be aware that the temporary table only exists for the
connection that created it.
Once that connection closes the table is dropped, also that table is
only visible to the connection that created it.
Dave
> n(AopUtils.java:287)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
> npoint(ReflectiveMethodInvocation.java :181)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed
> (ReflectiveMethodInvocation.java:148)
> at
> org.springframework.orm.hibernate3.HibernateInterceptor.invoke
> (HibernateInterceptor.java :97)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed
> (ReflectiveMethodInvocation.java:170)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke
> (JdkDynamicAopProxy.java :176)
> at $Proxy75.delete(Unknown Source)
> at
> es.indra.vipet.appcrud.domain.crud.CameraManageableServiceBase.delete(
> CameraManageableServiceBase.java:88)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
> Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at
> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflectio
> n(AopUtils.java:287)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoi
> npoint (ReflectiveMethodInvocation.java:181)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed
> (ReflectiveMethodInvocation.java:148)
> at
> org.springframework.orm.hibernate3.HibernateInterceptor.invoke
> (HibernateInterceptor.java:97)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed
> (ReflectiveMethodInvocation.java:170)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke
> (JdkDynamicAopProxy.java:176)
> at $Proxy76.delete(Unknown Source)
> at es.indra.vipet.appcrud.domain.crud.ManageCamera.delete
> (ManageCamera.java:147)
> at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native
> Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.apache.struts.actions.DispatchAction.dispatchMethod
> (DispatchAction.java:274)
> at org.apache.struts.actions.DispatchAction.execute
> (DispatchAction.java :194)
> at es.indra.vipet.appcrud.domain.crud.ManageCamera.execute
> (ManageCamera.java:22)
> at
> org.apache.struts.action.RequestProcessor.processActionPerform
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
> ( CameraManageableDaoBase.java:380)
> ( ManageCamera.java:22)
> at
> org.apache.struts.action.RequestProcessor.processActionPerform
> (RequestProcessor.java:419)
> at org.apache.struts.action.RequestProcessor.process
> ( RequestProcessor.java:224)
Can you get a trace of the SQL commands sent to the server? One way to
get that is to set the log_statement configuration parameter in your
postgresql.conf file to "all".
That would help diagnosing the problem.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Yep. I don't know where the create table statement is coming from;
Hibernate, AndroMDA or your application code, but apparently it needs to
be changed to "on commit delete rows".
Or maybe you're supposed to be running the statements as a single
transaction, but you're not?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?