Stick to commen-sense conventions

I implemented an update by deleting and recreating an entity, thinking this would have no consequences (mainly because the weak foreign keys stayed the same and I expected access would happen through these keys). But I added another independent guid, and then there was a problem that because the guid changed, a client could no longer retrieve the object.

XCS clustering problem

XCS wasn't responding. Logs showed things about GMSImpl, wrongMethod() suspect(). It was trying to join cluster but something was going wrong.

Removing XmotionSessionCache-service.xml stoppedt his.

java.lang.OutOfMemoryError: PermGen space

Monitor memory sizes through jboss by invoking listMemoryPools() of ServerInfo jmx object in the jmx-console

wire up your relationships!

Again I got caught by not wiring up my ejb bidirectional relationships. As an example I had GeoFence (gf) and GeoFenceDataSet (ds). gf has one ref to ds and ds has lazy collection of gf's.

I never understood why I need to do a ds.getGeoFences().add(gf). I thought this should be magically looked after whenever I create a gf with gf.setDataSet(ds). In particular what I saw was, I would do the following within a transaction

em.persist(gf)
em.flush()

and then

for (gf : ds.getGeoFences() )

in a separate transaction. Since my collection was lazy-loaded, I expected the newly added gf to be in that collection, since it should have been loading the collection from the database, but it didn't. It looks like the entity manager knows whether to read in collection or not. It seems to keep track of the ds verison number and the last gf id it should know about.

sql server and collation

http://www.databasejournal.com/features/mssql/article.php/10894_3302341_2
http://blogs.msdn.com/michkap/archive/2005/11/08/490305.aspx
http://www.madprops.org/cs/blogs/mabster/archive/2007/07/02/sql-collation-made-easy.aspx

Default collation depends on how sql server was installed.

Looks like SQL collations were just for sql server, and windows collations are for the whole of windows.

Hiding and Showing table rows

Note - to show the row again, set its display to empty string, not to inline/block which doesn't work in firefox



document.getElementById('radiusRow').style.display = ''

RMI lookupds using 192.168.0.3 instead of localhost

When my Transporta was trying to connect to XCS for the session store bean, it was trying to connect to 192.168.0.3 (my ip address when connected to wireless at home). This was puzzling as I had set the java.naming.provider.url to localhost:1199. I event tried making it 127.0.0.1 thinking maybe there was a problem with the resolving of name localhost, or I thought maybe somewhere the lookup was being cached.

The problem was resolved by restarting XCS and is explained as follows: with RMI, the client asks uses java.naming.provider.url for a remote reference, the server responds with a server hostname and port to use to get that object. XCS was sending back its server hostname of 192.168.0.3, it hadn't updated itself since my ip changed.

From http://java.sun.com/j2se/1.4.2/docs/guide/rmi/faq.html#nethostname

For an RMI client to contact a remote RMI server, the client must first hold a reference to the server. The Naming.lookup method call is the most common mechanism by which clients initially obtain references to remote servers. Remote references may be obtained by other means, for example: all remote method calls can return remote references. This is what Naming.lookup does; it uses a well-known stub to make a remote method call to the rmiregistry, which sends back the remote reference to the object requested by the lookup method.

Every remote reference contains a server hostname and port number that allow clients to locate the VM that is serving a particular remote object. Once an RMI client has a remote reference, the client will use the hostname and port provided in the reference to open a socket connection to the remote server.