最近公司要将应用程序放到weblogic集群中去运行,而一开始的开发和测试全部都是在单weblogic上运行的.于是,出现了一些问题...
1. 在非集群中的应用系统可以很好使用的类静态变量问题:
如果该变量是final的,那没问题.一旦需要动态修改该变量的值,那么在集群中将不能很好的运行.因为集群中的一个weblogic实例中修改值后不会主动同步更新其他实例.weblogic技术支持建议共享变量最好使用数据库,如果要使weblogic集群同步更新可以使用jndi树,但这种效率不会很好,且当这个变量很大的时候尤其严重.
2. 开发集群中的应用系统时,需要注意操作session的方式和时机:
2.1 为session节点赋值/改值/移除时一定要使用setAttribute(取值时用getAttribute)/removeAttribute方法,只有使用这个方法时,weblogic集群才会触发事件通知对应的备用实例更新session信息(补充: weblogic集群运行时,每个实例(primary)都会为每个用户请求找一个备用实例(secondary)存储session等信息,且实时的将session的变动通知备用实例.这样当一个实例down掉以后,用户的请求会被主动转发到备用实例进行处理响应,且同时会再找一个实例作为它的备用实例).
2.2 在调用set/removeAttribute方法后,不要在修改该节点用的变量的值,这样的改动是不会被通知到备用实例中去的,于是会导致session信息不同步的现象.
未完,待续...
1. 在非集群中的应用系统可以很好使用的类静态变量问题:
如果该变量是final的,那没问题.一旦需要动态修改该变量的值,那么在集群中将不能很好的运行.因为集群中的一个weblogic实例中修改值后不会主动同步更新其他实例.weblogic技术支持建议共享变量最好使用数据库,如果要使weblogic集群同步更新可以使用jndi树,但这种效率不会很好,且当这个变量很大的时候尤其严重.
2. 开发集群中的应用系统时,需要注意操作session的方式和时机:
2.1 为session节点赋值/改值/移除时一定要使用setAttribute(取值时用getAttribute)/removeAttribute方法,只有使用这个方法时,weblogic集群才会触发事件通知对应的备用实例更新session信息(补充: weblogic集群运行时,每个实例(primary)都会为每个用户请求找一个备用实例(secondary)存储session等信息,且实时的将session的变动通知备用实例.这样当一个实例down掉以后,用户的请求会被主动转发到备用实例进行处理响应,且同时会再找一个实例作为它的备用实例).
2.2 在调用set/removeAttribute方法后,不要在修改该节点用的变量的值,这样的改动是不会被通知到备用实例中去的,于是会导致session信息不同步的现象.
未完,待续...