Hi everyone!
a quick question here:
I have a proyect developed using EJB3.0, JSF1.0 and oracle 10g
well I show a datatable using a ejb query. I update a table directly into my DB using oracle sql developer (SQL Query)
and the update value (i.e employee name) doesn't appear on screen, only the old value appears
but if I delete or insert something in my DB using SQL commands it does show it.
If I stop and reRun the app it does show.
but not when updating why is that? and how can I solve it? thanks in advance!

I don't think is a bug, it only happens when I externally update a table in my case using oracle sql developer. Well when I create a new JSF JSP it shows : JSF Core: 1.0 and JSF HTML 1.0 is it jsf1.0? how can I tell which version I got.

No, a persistence cache... Why do you think I ask about JPA if I would be referring -again- to the browser cache?

Your problem description seems to point to one being in place because when you would update the record through JPA (EJB has very little to do with it - know the tech you work with) then the persistence cache would get updated while if the data is updated anywhere else the data in the cache would not get updated until the cache is cleared.

If the architecture called for JPA then you should not be updating data in the database outside of JPA if the data is also accessed by the entities.
Sneaking in behind JPA's loses all the advantages that you chose JPA for in the application.
Even if you disable the second level cache, you will still have inconsistencies and delayed updates because some data will always be stale.

r035198x wrote:
If the architecture called for JPA then you should not be updating data in the database outside of JPA if the data is also accessed by the entities.

That is no rule, a sane architecture allows for that to happen.

Sneaking in behind JPA's loses all the advantages that you chose JPA for in the application.

Not really. The major advantage of JPA or any other ORM layer is to have an object oriented approach to the data, such things as being less tied to a specific database vendor and caching are an added bonus.

Even if you disable the second level cache, you will still have inconsistencies and delayed updates because some data will always be stale.

I can't speak for you, but I've never had any problems with it. And in fact I don't use a 2nd level cache unless I really need to, which is hardly ever.

Just don't hold on to data when you don't need to, that is the only trick you need.

gimbal2 wrote:
That is no rule, a sane architecture allows for that to happen.

With results exactly like the OP is getting.
>

Sneaking in behind JPA's loses all the advantages that you chose JPA for in the application.

Not really. The major advantage of JPA or any other ORM layer is to have an object oriented approach to the data...

And that advantage is lost when you sneak in behind. The solutions that JPA solved for you are lost and you have to solve them again. The errors that JPA shielded you from resurface.

Even if you disable the second level cache, you will still have inconsistencies and delayed updates because some data will always be stale.

I can't speak for you, but I've never had any problems with it. And in fact I don't use a 2nd level cache unless I really need to, which is hardly ever.

The point was that you will have always have stale data if you update the db outside the application until the persistence provider session has synced with the DB again. This is true even if you use JDBC.

r035198x wrote:
The solutions that JPA solved for you are lost and you have to solve them again. The errors that JPA shielded you from resurface.

You seem to believe that JPA is some kind of magic wand. It is not, it does not solve problems. It makes specific tasks easier (like mapping data to an object tree and the other way around), not more secure. It does not protect the programmer from himself and it is not its task to do so.

There is no "sneaking in from behind" either. It is perfectly valid to reference a database from multiple independent sources - that's why the darned things do what they do!