jesus - if you are going to suggest people to do this then please warn about the fact that you are ignoring everything that has to do with transactional or even conversationel integrity.

The code suggested in this thread makes the access transparent but it also makes it impossible to effectively guard against data consistency and effective data loading.

Hi Max



That is exactly the problem... Is there any way around this?

I am afraid that I think it is not possible for me to change how Spring Rich Client work with the collection in this case. When you have complex master/details structure and that you may want to add or remove an item (see http://opensource2.atlassian.com/conflu ... ageId=2579

for instance the "Education is a list of the items created in the table"


Any suggestion around this issue? Otherwise... I may have to stick with my dangerous code...

Thanks
Benoit

max, I don't see how we ignore transactional integrity.

Once again the problem:
1. hibernate loses the session when proxies are transmitted to the RMI-client.
2. if you do want lazy loading, you must send a callback to the client to init/load any associated object or collections that is requested by the client.

dealing with re-associating detached proxies is quite tricky, but there is hardly any other way. If you know any better solution pls let me know it.


marc

I dont know why spring rich client framework forces you to call setList() insstead of using real mutators (and i'm surprised if they require that)

Regarding fetching stuff for a rich client, then I would rather have the fetching done explicitly instead of hide it make developers think it is possible to do transparently.

And the data has breached transactional integrity because it crosses the vm and tx borders...because it is a client that is "lazy fetching data" it is in some sense its ok to do - but one should be extremely carefull about it.

Spring and indirectly Spring Rich client will take an attribute say "address" and put in directly in a table
where we have this object:
public class Person {
...
List getAddress()
...

List is provided by auto-fetching (not lazy) on the EJB server and the Person object is returned to the GUI. It is a list of Address objects.

Furthermore, Spring RC will let you add/remove addresses. at the end, it will replace the existing List with the new one. If you do not want the change, it is easy to "Revert" since the original list was copied for you (again Spring Rich Client).

You mentioned that a modified object should not be re-attached but when I send it back to the server, will it be saved ok if I simply say session.merge(modifiedPerson)?

Are we 100% sure that a clear/set should try to reconnect to the DB??? Most Hibernate mapping generated (say with MyEclipse) would simply provide get/set(Collection) for any 1:n relationship... So I'd have to write a fair amount of accessors to go round the fact that a list collection shall not be changed?

thanks for your help.

Benoit

well I'm doing my best to add addX()/removeX() to the pojo's generated by hbm2java.

But it does not change that you should still manipulate the collection and not clear it out since you then loose the persistent information.

HI Max

Just to clarify in my mind. When you say that the "new" set of data has lost the persistent information, what does that mean concretely?

If I have an Person that has 2 addresses a1 and a2. In the GUI I change that to a1 and a new a3 (a2 removed from the list) and the entire list has been replaced with a new one.

I then send the object to the ejb server that does session.merge(myNewPerson).

are a1 and a3 going to be saved? and a2 removed?
Is it slower than if the list still contained the persistence info?

One thing though is that I am careful in defining discrete set of info and objects that are passed back and forth. I do not have a whole universe linked just discrete pockets.

Thanks again.

Great to have an 'official' Hibernate viewpoint...

Benoit

i guess its somewhat ok with merge() but I would test it deeply before counting on it ... there are some suttleties in merge semantics (for good reasons) that can result in more deletes/inserts then one could naively expect.

but in general the more persistence info you have in your object graph the more efficient/correct will it be.

Sorry to reopen an old thread but I think that an hibernate-client.jar would be very helpful for swing developpers.

I tried to do so and it seems quite feasible. In my case, I just replaced Persistent collection implementation on the client side with other implementations that just delegate code to java.util implementations and don't rely on hibernate engine : does this make sense.

Max, Is this hibernate-client.jar available somewhere ?

Thanx

Seb

i dont know where it is at the moment. best thing is to ask in the jboss dev forums where someone might know more about it.

So there is no plan to include such a jar in an official released ?

eh - i did not say that did i ? :)

I just said i don't know the state of it at the moment. Feel free to dust it up and provide patches.

It must be possible to implement safe remote initialization, stateful bweans are designed for this use case. Custom lazy initializer can be used to deserialize callback.

cesbron,

If you locate this grail (hibernate-client.jar), could you post coordinates here?

Also, how does EJB3 deal with this issue (which is major).

I just came across this thread. I am developing a hibernate/spring client/servier project with a swing frontend. My backend is rmi or httpinvokers through spring(i can't decide which one).

Anyways I am new to spring/hibernate and i have found that issues like these are very frustrating to tackle being that most people are using spring particularly and hibernate in a web environment where a lot of these detached session issues don't come into play.

While my solution might not be popular i think it is the only currently safe solution. From what i can see doing things that try to reattach the session remotely is very difficult and requires so much plumbing code it almost discourages the use of hibernate. The other option often mentioned is to just not use lazy initialization. Although this works i think it reduces the value of hibernate immensely. If you are going to use hibernate you need to take advantage of this feature. Sure you can still do so on heavy backend processes but you are really changing the nature of the beast. I believe the hibernate team made lazy initialization a default for a reason.

So my solution is to use DTOs for everything that the view needs I know DTOs,oooo evil. But seriously most people call DTOs evil are speaking in the contexst of a web application. The DTO pattern is a natural pattern for an architecture with a remote client. First of all hibernate domain objects are very heavy by nature. You graph your whole object model so if you aren't using lazy initialization it is very possible that your hibernate objects are HUGE. Serializing and sending that kind of data over the net is not going to be all that fast. Remote client architecture means you need to concentrate on speed over the wire so resorting to a DTO object that contains just the info you need for each view makes sense. The thing that sucks about this though is you sort of have to be redundant. You have to create a DTO for each view and write code to transform this data back and forth. (reminds me of cobol) You can work this into a simple framework that makes it easier to do. But I believe this is the right way to do it. You shouldn't design your backend domain model around your view. You should design your backend as flexible as possible, hence heavy hibernate objects, and then make it work with your view. The view is ever changing and is the one thing you should depend on to be steady. You might change to a web view who knows.