glassfish_at_javadesktop.org wrote:
> The other model is a generic, standalone client. This model is
> perfectly workable, and has no real dependencies on the app server.
> Consult the Glassfish EJB FAQ for details on this.
Thanks, I was able to get one of those up and running very quickly after
reading the FAQ. I think that's exactly what we're looking for. I
haven't tried it across machines yet, but that doesn't seem like it
would be a problem.
The only thing that concerns me is whether having the remote interfaces
in place (we weren't planning that for now) will slow the web app down?
> You WILL potentially have issues with "quick SQL fixes", depending on
> their nature and how they are done. JPA caches much of it data, and a
> classic issue would be going in to the DB and, say, changing a flag
> on a customer record. Odds are if that customer has already been
> cached by the JPA, your application will not see the change.
Exactly what we're concerned about.
> One mechanism to avoid this is rather than doing "quick SQL fixes",
> instead, do "quick EQL fixes". And by that I mean create a simple,
> secure (natch), client to your EJB tier that can take arbitrary EQL
> statements and execute them.
I thought of that, but didn't want to admit it :) But if we can get
standalone clients working, we can write single-use programs for things
like that.
--
____________________________________________________________
Glenn Holmer gholmer_at_weycogroup.com
Software Engineer phone: 414-908-1809
Weyco Group, Inc. fax: 414-908-1601