Hi,
On Friday, November 14, 2014, Romain Manni-Bucau <rmannibucau_at_gmail.com>
wrote:
> 2014-11-14 19:06 GMT+01:00 arjan tijms <arjan.tijms_at_gmail.com
> <javascript:;>>:
> > Hi,
> >
> > On Thursday, November 13, 2014, Romain Manni-Bucau <
> rmannibucau_at_gmail.com <javascript:;>>
> > wrote:
> >>
> >> Is it a real issue or just a theorical one? I mean default resources
> >> are generally a bad choice for real apps since you are not sure what
> >> you get so for me their purpose is related to testing so is that such
> >> a big deal?
> >
> >
> > I agree that the default resources are primarily a facility for
> tutorials,
> > people just starting, testing and simple applications.
> >
> > Yet, a "simple application" does not necessarily mean non-production
> > application and even does not mean non-critical application. So I don't
> > agree that a "real application" should not use default resources.
> >
> > For instance running apps that have modest persistence requirements in
> > resource constrained environments (think IoT among others) the default
> > datasource is an extremely convenient facility. In such environments and
> for
> > such apps installing a full blown external DB is often not only
> unnecessary
> > but also not even possible.
> >
> > It's true that a portable app would not know what the exact nature of the
> > persistent store is, but A) if the persistence requirements are modest
> this
> > may not matter and B) for actual deployments to a specific server this
> -is-
> > of course known.
> >
>
> Well doing it you accept to potentially make you server crashing or
> not responding. "modest" is the same as "default". it doesn't define
> anything so you can't rely on it if your app is used.
I don't quite agree with that either ;)
The default datasource gives you a guarantee that you can put data into it
and get it out later. This may simply be all that's needed. For an IoT
device, eg something for home automation, it may be a matter of storing
only a few values during the day, then provide a small report at the end of
the day.
Why should that crash the server? Are we also afraid that the HTTP stack
spontaneously crashes, since a server gives us a "default stack" that we
didn't provision externally?
And why would that make the app unresponsive? Maybe there's not even a
responsiveness to speak about, since the app is largely operating in batch
mode?
Not everything is an interactive server processing potentially many
concurrent user requests.
> This is not a matter of size, just of control of what is done which is
> mandatory when going in production.
But what level of control do you miss if the only requirement is to
temporarily store values and read them back later?
I do agree that the default datasource may be improved by allowing some
level of control or to assert some capabilities. For instance some kind of
setting somewhere to control whether the default datasource persists to
stable storage or to volatile (in-memory) storage would be great.
If the app needs somewhat more control, but still is relatively modest, it
can also opt to use the embedded datasource and eg configure it to use an
app provided embedded H2 DB using @DataSourceDefinition (another facility
that is sometimes said not to be suitable for "real apps", which IMHO is
not correct either).
The beauty of Java EE, specifically when using JPA and/or CDI producers for
datasource injection, is that one can fairly transparently upgrade from one
to the other, without changing code all over the place.
> > Java EE servers are increasingly being used for smaller and smaller
> > applications, and I think that's a very exciting thing. IMHO Java EE
> should
> > be able to both scale up and down, and default
> >
>
> I agree on this but today it is not possible. However spec can be
> enhanced to make it real.
Various Java EE servers do run on a raspberry pi today ;)
And as for the programming model scaling down (for the sake of simple apps,
not necessarily resource constrained ones) this had already been happening
since EE 5. I think we just need to ensure that we continue on this path,
and IMHO stop saying that things like embedded resources and embedded
authentication modules, as well as default resources are not for real apps
and are not for production.
It really depends on the app. Embedded and default resources can be
completely wrong for one situation, but totally make sense for another one.
Kind regards,
Arjan Tijms