[JBoss-dev] [ jboss-Bugs-621270 ] invalid SQL is generated for MSSQL
Bugs item #621270, was opened at 2002-10-10 14:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=621270group_id=22866 Category: JBossCMP Group: v3.0 Rabbit Hole Status: Open Resolution: None Priority: 8 Submitted By: Alexei Yudichev (sflexus) Assigned to: Nobody/Anonymous (nobody) Summary: invalid SQL is generated for MSSQL Initial Comment: I have the following EJBQL expression: SELECT DISTINCT OBJECT(c) FROM StoreCategory c, IN (c.locales) l WHERE l.code=?1 AND c.images IS NOT EMPTY which for postgresql translates into: Executing SQL: SELECT DISTINCT t0_c.id FROM storecategory t0_c, mmslocale t1_l, storecategory_locales_m_18q3els t2_c_locales_RELATION_TABLE, mmsimage t3_c_images, mmsimage_storecategorie_1diogue t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND TRUE) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) and executes normally. But for MSSQL I get: SELECT DISTINCT t0_c.id FROM StoreCategory t0_c, MMSLocale t1_l, StoreCategory_locales_MMSLocale_storeCategories t2_c_locales_RELATION_TABLE, MMSImage t3_c_images, MMSImage_storeCategories_StoreCategory_images t4_c_images_RELATION_TABLE WHERE (t1_l.code = ? AND 1) AND (t0_c.id=t4_c_images_RELATION_TABLE.StoreCategory AND t3_c_images.id=t4_c_images_RELATION_TABLE.MMSImage AND t0_c.id=t2_c_locales_RELATION_TABLE.StoreCategory AND t1_l.code=t2_c_locales_RELATION_TABLE.MMSLocale) which leads to java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC][SQLServer]Line 1: Incorrect syntax near ')'. Why not using AND 1=1 instead of AND 1? -- Comment By: Dirk M. Sohn (dsohn) Date: 2002-10-21 22:03 Message: Logged In: YES user_id=595100 He was right due to my tests. I had the same problem with a NOT EMPTY over a relation and MS SQLSERVER 2000. JBoss-3.0.0 generated AND (TRUE) JBoss-3.0.3 genetared AND (1) but AND (1=1) does the work. I changed true-mappping in standardjbosscmp-jdbc.xml to type-mapping nameMS SQLSERVER2000/name true-mapping(1=1)/true-mapping and it works now. There migth be the same problems in Bug #626468 too. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-10-14 08:19 Message: Logged In: YES user_id=345880 I've just tested SELECT * FROM LIST$COMP_SUBCATS WHERE SUBCATEGORYID1=(1=1) And got Line 1: Incorrect syntax near '=' error message. So seems ejbql compiler needs to be redesigned a bit in order to distinguish booleans as in the original query (WHERE 1) and booleans as in this query (WHERE SUBCATEGORYID1=(1=1)). -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-10-12 16:42 Message: Logged In: YES user_id=543482 Have you really tested it with MS SQLSERVER and has it failed? I don't have MS SQLSERVER to test. But I've tested it against MySQL that have true-mapping the same as MS SQLSERVER does. And it works fine: select * from document where sent=(1=1) Field 'sent' is boolean and represented in the db as '1'. -- Comment By: Alexei Yudichev (sflexus) Date: 2002-10-11 23:50 Message: Logged In: YES user_id=345880 Isn't the same boolean mapping used for dealing with boolean types in queries like SELECT ID FROM FOO WHERE SOME_BOOLEAN_FIELD=?1 ? If so, substituting (1=1) will crash such queries: SELECT ID FROM FOO WHERE SOME_BOOLEAN_FIELD=(1=1) That's why I posted this as a bug. -- Comment By: Alexey Loubyansky (loubyansky) Date: 2002-10-11 10:20 Message: Logged In: YES user_id=543482 If I got you right, it's the problem with true-mapping. Currently, for MS SQLSERVER: true-mapping1/true-mapping false-mapping0/false-mapping I am not familiar with MS SQLSERVER but if you are sure it should be true-mapping(1=1)/true-mapping false-mapping(1=0)/false-mapping like for Hypersonic, I'll fix it. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=621270group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] JBoss 4.0 Entity Redesign
On 2002.10.21 10:50:45 -0400 Bill Burke wrote: 1. Interceptors do not belong in the JMX layer. JMX should stay simple. If you want interceptors in front of an MBean, you should make the MBean an aspect. Let's gut out the JMX interceptors in favor of using Hiram's Aspect stuff when its mature enough. I disagree. Juha implemented the mbean server based on interceptors for the same reason most of jboss is based on interceptors. I think there should only be one kind of interceptor stack, used for mbeans, clients, aspects, ejbs. In the server, what's on the top makes it an mbean. In a client, it can be the proxy. For aspects, maybe something else. But we only need one kind of interceptor (as in interface that all interceptors implement and how do we invoke each interceptor in the stack, not as in they should all be stateless/ful). For ejbs, this will translate into a slightly odd kind of mbean, since there won't exactly be one particular object at the end of the stack, but rather the instance will get selected by one of the interceptors. 2. I really don't like this idea of storing state in some detached hashmap somewhere. You're getting back to functional programing with structures and functions. I agree with Marc, hashmap.getvalue is just plain unreadable as well. Hiram, example of state? An example is the Nuke pattern for replicated SFSB. The state of the SFSB stays with the client in the vent of a total destruction of the server. The client provides the state in the event of a failover. Another is IDEMPOTENT methods. Idenpotent methods return the same value no matter what. An interceptor knowing this could store the state of the returned method call and avoid a remote invocation. The above are examples of state per instance. Now I believe you would have singleton interceptors that needed to maintain state. An example is a client side interceptor that does clustering, loadbalancing and failover. It needs to maintain a list of available nodes. There are kind of 3 kinds of state: Configuration of interceptor instances of the same class, conceptually from some kind of interceptor factory. This should definitely be kept in the interceptor instance. Related to this is which interceptors are in the stack. Both of these are currently recorded in jboss.xml as a config-name for ejb stacks. State of interceptor instances depending not on stack name but on identity the top of stack object. This includes, for ejbs, stuff like local jndi environment, security proxy instances, tx-method associations. I think this is what we are debating. I think it will lead to significantly simpler stack management and clearer thinking about interceptors to store this in a hashmap at the top of the stack. If this state info is stored in the interceptors, you need an instance of the interceptor for each top of stack object. If it is store in the top of stack object, you only need one instance of each interceptor for each stack definition. Currently, most interceptors are stateless in this way, although many already are stateless because they store the state info in the top of stack object. I'm proposing that we formalize this and make the remaining interceptors (such as security proxy) use this model as well. Thirdly, there is state from the method invocation. I think everyone agrees that this state should stay in the method invocation, and we should not create and configure a stack for each invocation. david jencks Bill -Original Message- From: [EMAIL PROTECTED] [mailto:jboss-development-admin;lists.sourceforge.net]On Behalf Of Hiram Chirino Sent: Sunday, October 20, 2002 11:25 PM To: [EMAIL PROTECTED] Subject: RE: [JBoss-dev] JBoss 4.0 Entity Redesign I think for simplicity we should have only stateless interceptors, any interceptor can store per-stack state in a the stack top in a hashmap. I rewrote the mbean interceptors this way, it works fine, but then juha committed a completely different reimplementation. David there is no reason to enforce one. We need both coding styles it is easier. I don't think it is easier to always code invocation.getValue(COMMIT-OPTION); as opposed to commitOption when the commit option is configured at deployment. Clearly we can achieve the same result but there is we shouldn't enforce one. When you guys talk about statefullness.. I get a little lost. Marc, is that commitOption statefull: (1) per proxy interceptor instance. 1 interceptor instance is created for each DP. (2) per stack interceptor instance. 1 interceptor instance is created for a stack (shared by DP). Right now the aspect stuff does (2), but you can do the invocation.attachments.get(COMMIT-OPTION); to get a value that was attached to the DP. Regards, Hiram --- This
[JBoss-dev] [ jboss-Bugs-626540 ] exceptions from mbean-info-db-service
Bugs item #626540, was opened at 2002-10-21 22:49 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626540group_id=22866 Category: None Group: v4.0 Status: Open Resolution: None Priority: 5 Submitted By: Frank Langelage (lafr) Assigned to: Nobody/Anonymous (nobody) Summary: exceptions from mbean-info-db-service Initial Comment: The deployment of mbean-info-db-service.xml gives me exceptions on startup of jboss-head. See attached extract from server.log. (JBoss-Head, current checkout, JDK 1.4.1 on Linux ) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376685aid=626540group_id=22866 --- This sf.net emial is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
[JBoss-dev] [ jboss-Patches-626646 ] Patch for Failover with Sticky Sessions
Patches item #626646, was opened at 2002-10-22 01:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=376687aid=626646group_id=22866 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Rakesh Krishnan (raksk) Assigned to: Nobody/Anonymous (nobody) Summary: Patch for Failover with Sticky Sessions Initial Comment: This patch is for JBoss-3.0.3_Tomcat-4.0.5 (should work with Tomcat4.1.12 as well) . Servers S1 S2 use sticky sessions + session replication have distributed apps deployed on them. Kill S1, try to continue in the same session - loadbalancer redirects to S2, S2 gives NullPointerException (see below ) When using sticky sessions (with jvmRoute appended to JSESSIONID) , failover was not happening because responseThreadLocal.get() was returning null - since the server on which the thread existed had died. Added code which checks whether a response object exists and addCookie() only if it exists.Also works for condition where the 'dead' server is back 'live' and has re-joined the cluster. Iam basically ignoring the pass where responseThreadLocal.get() returns null, if there was a way to 'revive' a new response in the same pass that would have been better. Here's the exception : 2002-10-14 14:40:21,642 DEBUG [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] Looking for sessions that have expired 2002-10-14 14:40:57,093 DEBUG [org.jboss.web.catalina.EmbeddedCatalinaServiceSX] Looking for session with id=NsLuDM0DMSL+MeuDgdt3Vg**.tomcat1 2002-10-14 14:40:57,103 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSession Service] getHttpSession called for session: NsLuDM0DMSL+MeuDgdt3Vg**.tomcat1 2002-10-14 14:40:58,014 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSession Service] removeHttpSession called for session: NsLuDM0DMSL+MeuDgdt3Vg**.tomcat1 2002-10-14 14:40:58,024 DEBUG [org.javagroups.DefaultPartition] [Mon Oct 14 14:40:58 PDT 2002] [INFO] NAKACK.send(): sending msg #1 2002-10-14 14:40:58,024 DEBUG [org.javagroups.DefaultPartition] [Mon Oct 14 14:40:58 PDT 2002] [INFO] STABLE.startStableTask(): stable task started; num_gossip_runs=3, max_gossip_runs=3 2002-10-14 14:40:58,024 DEBUG [org.jboss.ha.httpsession.server.ClusteredHTTPSession Service] removeHttpSession called for session: NsLuDM0DMSL+MeuDgdt3Vg**.tomcat1 2002-10-14 14:40:58,024 ERROR [org.jboss.ejb.plugins.LogInterceptor] EJBException, causedBy: java.lang.NullPointerException at java.io.ByteArrayInputStream.init(Unknown Source) at org.jboss.ejb.plugins.CMPClusteredInMemoryPersistenc eManager.loadEntity (CMPClusteredInMemoryPersistenceManager.java:352) at org.jboss.ejb.plugins.CMPPersistenceManager.loadEntit y(CMPPersistenceManager.java:410) at org.jboss.ejb.plugins.EntitySynchronizationInterceptor.inv oke(EntitySynchronizationInterceptor.java:262) at org.jboss.ejb.plugins.EntityInstanceInterceptor.invoke (EntityInstanceInterceptor.java:152) at org.jboss.ejb.plugins.EntityLockInterceptor.invoke (EntityLockInterceptor.java:107) at org.jboss.ejb.plugins.LogInterceptor.invoke (LogInterceptor.java:203) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:493) at org.jboss.ejb.Container.invoke(Container.java:712) at org.jboss.ejb.EntityContainer.invoke (EntityContainer.java:1058) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.invocation.local.LocalInvoker.invoke (LocalInvoker.java:98) at org.jboss.invocation.InvokerInterceptor.invoke (InvokerInterceptor.java:102) at org.jboss.proxy.TransactionInterceptor.invoke (TransactionInterceptor.java:77) at org.jboss.proxy.ejb.HomeInterceptor.invoke (HomeInterceptor.java:189) at org.jboss.proxy.ClientContainer.invoke (ClientContainer.java:76) at $Proxy15.remove(Unknown Source) at org.jboss.ha.httpsession.server.ClusteredHTTPSessionS ervice.removeHttpSession (ClusteredHTTPSessionService.java:153) at java.lang.reflect.Method.invoke(Native Method) at org.jboss.mx.capability.ReflectedMBeanDispatcher.invok e(ReflectedMBeanDispatcher.java:284) at org.jboss.mx.server.MBeanServerImpl.invoke (MBeanServerImpl.java:517) at org.jboss.util.jmx.MBeanProxy.invoke (MBeanProxy.java:174) at $Proxy232.removeHttpSession(Unknown Source) at org.jboss.web.catalina.session.ClusterManager.removeS ession(ClusterManager.java:496) at org.jboss.web.catalina.session.ClusterManager.remove (ClusterManager.java:277) at org.jboss.web.catalina.session.ClusteredSession.setId (ClusteredSession.java:348) at org.jboss.web.catalina.session.ClusterManager.findSessi on(ClusterManager.java:209) at org.apache.catalina.core.StandardHostValve.invoke (StandardHostValve.java:173) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:566) at org.apache.catalina.valves.ErrorDispatcherValve.invoke (ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline.invokeNext (StandardPipeline.java:564) at org.apache.catalina.valves.ErrorReportValve.invoke
