[redijedi]

Nonsense.

1) ...4)

1) Right. I typically would not attempt to do so. After using the EJB3 entity class B in the previous example in this manner successfully, I was misled to believe that this was something that could be done in the new implementation. My bad. However, it did work in the one case. It stopped working when I made the SecondaryTable change to bean A. I believe this behavior is inconsistent.

2) I wasn't so much looking for a long persistence context as much as an object to intelligently handle that (create persistence context, etc.) when I call a method that requires lazy loading. Again, the behavior I experienced before adding the SecondaryTable suggested to me that this was what was happening.

3) Not blaming EJB spec. I was under a false impression based on experimenting.

4) I will look into it. Thanks.

All together, I did not mean to rile the well-respected Gavin King. I do seem to be experiencing inconsistent behavior.

[redijedi]

"martin ganserer" wrote:
Hello redijedi,

maybe it is a hack for you.

Regards

Did not mean anything by this comment other than it seems to be a work around for a situation that I didn't think should have existed in the first place.

[danch1]

"redijedi" wrote:

Nonsense.

1) ...4)

1) Right. I typically would not attempt to do so.

But you seem to expect the container to be willing to do it for you. Not trying to beat up on you here, but think about what would happen if the container just went ahead and grabbed more data every time you traversed an association from entity to entity in any tier of the application. That implies a lot of begin transaction, grab a few columns, commit transaction action, which is a series of small requests (often accross the network, always cross process).

The spec as written forces the application designers and architects to think about what their access patterns will be and provides tools to allow us to explicately tell the container what we want it to do.

In short, the container is dumb to encourage us to think about what we're doing.

[javatwo]

I think the EntityManager should provide a method for user to load lazy entities and build object relationships.
something like:

void loadLazyEntity(entity, propertyName)

[javatwo]

I tried to tag a property as LAZY using
@Basic(fetch=FetchType.LAZY)

it did not work either. It is being treated as EAGER from generated SQL.

[rwallace]

In particular, you will need to understand the concept of FETCH JOIN, and the concept of open-session-in-view.

I understand the concept of open-session-in-view and have used this with Spring and Hibernate. This is one thing I've been trying to find some documentation for in exploring moving to JBoss and EJB3 from Spring and Hibernate. Do you have any pointers on how to do this in JBoss and EJB3? Is there a simple servlet filter like there is in Spring?

Thanks,
Rich

[renkrad]

"danch" wrote:

"redijedi" wrote:

Nonsense.

1) ...4)

1) Right. I typically would not attempt to do so.

But you seem to expect the container to be willing to do it for you. Not trying to beat up on you here, but think about what would happen if the container just went ahead and grabbed more data every time you traversed an association from entity to entity in any tier of the application. That implies a lot of begin transaction, grab a few columns, commit transaction action, which is a series of small requests (often accross the network, always cross process).

The spec as written forces the application designers and architects to think about what their access patterns will be and provides tools to allow us to explicately tell the container what we want it to do.
(...)

The objective of the specifications are to provide a standart of development, and above all ease the development costs, code keeping and it's improvement.
Wouldn't it be much easier for the developer just perform a find of a data row and from it beeing possible to get all the associated data without explicitly making a new query (executing a new finder with all the necessary parameters)?

Wouldn't it be much more understandable to have something like (1):

MyBean bean = myBeanSes.getMyBean();
// Handle bean data

// Provide the transparent access to the other beans
bean.getAllOtherBeans();

Or like this (2):

MyBean bean = myBeanSes.getMyBean();
// Handle bean data

/* Geting other beans (don't forget that it would be neccessary to explicitly get the session of the other beans in the code).*/
myOtherBeanSes.findOtherBeansByBeanId( bean.getId());

The example (1) is alredy possible to acomplish if not remote. What i don't understand is why to provide two diferent behaviours to the same 'thing'. Well one is remote is more expendable for several reasons, but that is the preocupation of the designer/developer and not "yours".

What i'm trying to say here is that, just because it causes slow downs does not mean that it's not a good way to use if it well used.

I was really impressed when i saw this new version and though "Bye bye value objects". Guess i was wrong...

Thanx,
Daniel Campelo