Actually, this will solve Miro's
need to have the shared flag provided for each single table instead of the
common database. Unfortunately, this will lead to the problem, that this
information can be inconsistent: If one bean in one container tells to be
shared, and another bean in another container tells to be not...?! This could
only avoided if the flag is not given in the deployment desciptor, but the
database.properties file, since this file is shared between containers in the
same JOnAS server.
[Halas,
Miroslav] Markus, you
solution is not any better, you will have to have two data sources and still
put the correct data source to the bean so you have the same problem if two
beans in two containers don't match. This is a configuration problem and not
application defect.
[Markus Karg] Miro, yes,
the solution with the two data sources will not solve this, so let's forget
that idea. Okay, so how do we solve that issue. What would you think of having
a list of exclusive table names given in the datasource.properties file of the
ressource? For there is only one database.properties file, it cannot be
inconsistent, and you'll have the possibility to tell JOnAS what ressources
are exclusive. Ain't that the best solution? There will be no information
twice, there will be no information too much or too less.
in any case,
if TX is committed, store back data to the DBMS
in any case,
if TX is rolled back, forget the data
[Halas,
Miroslav] But you will
have to discard the beans instance because the data no longer match the data
in the database
[Markus Karg] Yes,
that's true, but let's say that we do not discard the instance completely, but
only pool it, so we can reuse it for another bean. This will save time
for deletion/GC and creating new beans.
