Friday, March 14, 2008
Configure sql server 2005 express to allow TCP/IP connections
http://blogs.msdn.com/sqlexpress/archive/2005/05/05/415084.aspx
Tuesday, January 29, 2008
What is ENC
There is a difference between component namespace and appserver (global) namespace.
Each "component" has it's own ENC at java:/comp/env
When it declares a dependency, it binds it to a name in here, eg. java:/comp/env/ejb/SomeEJB
It looks it up using this name. It is up to the deployer to bind this name with the global appserver name of the required resource eg below of a sun-web.xml. The resource could physically be in another server.
jdbc/FooDS -- relative to java:/comp/env
jdbc/OracleDS -- global jndi name
They say directo global lookups are not portable because appserver global namespace is implementation-specific.
Mappend name in @Resource annotation is the global jndi name (gets rid of need for sun-web.xml). Name (has a default of classname/fieldname) is the name in java:comp/env
If you don't suppy a mappedname, and don't provide a mapping in xml, it will look up global jndi name which is the same as the resource dependency's name in java:comp/env
https://glassfish.dev.java.net/javaee5/ejb/compdependencies_xmlforum_nov15.pdf
Each "component" has it's own ENC at java:/comp/env
When it declares a dependency, it binds it to a name in here, eg. java:/comp/env/ejb/SomeEJB
It looks it up using this name. It is up to the deployer to bind this name with the global appserver name of the required resource eg below of a sun-web.xml. The resource could physically be in another server.
They say directo global lookups are not portable because appserver global namespace is implementation-specific.
Mappend name in @Resource annotation is the global jndi name (gets rid of need for sun-web.xml). Name (has a default of classname/fieldname) is the name in java:comp/env
If you don't suppy a mappedname, and don't provide a mapping in xml, it will look up global jndi name which is the same as the resource dependency's name in java:comp/env
https://glassfish.dev.java.net/javaee5/ejb/compdependencies_xmlforum_nov15.pdf
Monday, January 28, 2008
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.
Wednesday, January 23, 2008
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.
Removing XmotionSessionCache-service.xml stoppedt his.
Thursday, January 17, 2008
java.lang.OutOfMemoryError: PermGen space
Monitor memory sizes through jboss by invoking listMemoryPools() of ServerInfo jmx object in the jmx-console
Tuesday, January 15, 2008
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.
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.
Sunday, January 13, 2008
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.
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.
Subscribe to:
Posts (Atom)