> The config/domain.xml doesn't allow you to pick a
> JVM, however; only to
> configure it.
>
> In V2, you will need a completely different
> installation of glassfish,
> because it will always use the JVM defined as AS_JAVA
> in the
> config/asenv.conf file (that is the
> /path_to_glassfish/config directory;
> not the domain config directory). That variable must
> be defined in V2.
>
> In v3, if that variable isn't in the asenv.conf file,
> then glassfish
> will use whatever java binary is in your path. So you
> could have
> separate domains started in separate shells with
> different paths running
> the different domains.
>
> However, as always I'm curious as to what use case
> you have for a 64-bit
> JVM -- meaning does your heap really consume more
> than 3.5GB? If you're
> caching database values (JPA does that pretty much
> automatically) then
> that's one reason, but I'd be interested to hear
> another reason if it
> applies.
>
> Also, I completely agree with Alexis that the best
> workaround is to use
> a Java alternative :-)
>
> -Scott
Hi Scott, I guess we don't yet have a technical reason for using the 64 bit JVM. We were just thinking that it would be best to use 64 bit to accommodate any future demands.
It would be nice to standardize everything to 64 bit, but I don't have the source for this one critical 32 bit native library.
Since a 32 bit exe can run on a 64 bit OS, I'm thinking of trying Runtime.exec to run the native program outside the web server and thus avoiding the JVM problem.
Thanks for the quick and informative responses guys. This is a great forum.
[Message sent by forum member 'superstition_free' (superstition_free_at_yahoo.com)]
http://forums.java.net/jive/thread.jspa?messageID=384576