-
1. Re: basic persistence test
tom.baeyens Aug 24, 2007 10:14 AM (in response to porcherg)i'll have a look asap and let you know my feedback. that might be monday, though.
-
2. Re: basic persistence test
tom.baeyens Aug 24, 2007 10:56 AM (in response to porcherg)it looks awsome !
i didn't knew the junit trick to run the same testsuite with different configurations. cool !
is the next thing you're going to do db schema creation ? or something else ? -
3. Re: basic persistence test
porcherg Aug 28, 2007 5:58 AM (in response to porcherg)I updated the test and the OR mapping.
I have some problems with the mapping:
- What should be persisted in Environment and WireContext ?
I had the problem with the ProcessElement configuration field (for the test, I just persisted the WireDefinition as a serialized object)
- How to persist an ObjectReference ? (maybe this has a link with the previous question)
- More generally, what should be persisted as a serialized object and what should be in a separate table ?
regards,
Guillaume -
4. Re: basic persistence test
tom.baeyens Aug 28, 2007 6:11 AM (in response to porcherg)"porcherg" wrote:
- What should be persisted in Environment and WireContext ?
execution.environment should not be persisted"porcherg" wrote:
I had the problem with the ProcessElement configuration field (for the test, I just persisted the WireDefinition as a serialized object)
the configuration members in various process definition elements are still in flux, so they don't have to be persisted yet.
but at some point, WireDefinition s will have to be persisted. this implies mapping all the descriptors. that is something that you could start on. when you do that, try to make sure that you re-use columns. meaning that if you have 2 different discriptors with both a String member field, make sure that they map to the same column. this will only work for basic types, but it already reduces the nbr of columns significantly."porcherg" wrote:
- How to persist an ObjectReference ? (maybe this has a link with the previous question)
object references should have a memberfield that points to a descriptor. once the wire definitions, including the descriptors are mapped, that can be used."porcherg" wrote:
- More generally, what should be persisted as a serialized object and what should be in a separate table ?
nothing should be a serialized object
only the clob and blob objects will have binary info. but in that case, it's user information that is binary. no process information should ever be persisted in binary format. -
5. Re: basic persistence test
tom.baeyens Aug 28, 2007 6:15 AM (in response to porcherg)postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.
-
6. Re: basic persistence test
tom.baeyens Aug 28, 2007 6:16 AM (in response to porcherg)wirecontext must never be persisted, i think. only the wire definition and the descriptors
-
7. Re: basic persistence test
tom.baeyens Aug 28, 2007 6:19 AM (in response to porcherg)why is the close method added in persistence service ?
-
8. Re: basic persistence test
porcherg Aug 28, 2007 8:01 AM (in response to porcherg)"tom.baeyens@jboss.com" wrote:
why is the close method added in persistence service ?
Hibernate implementation uses this method to close the connection and to free some resources.
JPA implementation uses this method to close the entitymanager
I use this method to close the PersistenceService before closing the Environment.
I think we should not have multiple persistence service that we never close.
If we have a link between the PersistenceService and the Environment, we could remove this method.
Can we define the persistence service as a resource enlisted to the environment transaction ?
This way the connection would be closed with the environment.
Guillaume -
9. Re: basic persistence test
porcherg Aug 28, 2007 8:17 AM (in response to porcherg)"tom.baeyens@jboss.com" wrote:
postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.
postLoad methods are just a copy of the readResolve methods because I didn't want to introduce modifications in the existing code.
I'll try to modify Process and Node so that they have the behavior you described.
Guillaume -
10. Re: basic persistence test
porcherg Aug 28, 2007 10:58 AM (in response to porcherg)"tom.baeyens@jboss.com" wrote:
FYI: Note that the eagerInitNames in WireContext are for persistence performance. In theory, we could just loop over all the descriptors and ask if they have to be eagerly initialized. But when hibernate loads the descriptors map, it returns a map with all proxies. They are only loaded the first time they are accessed. So if only 2 out of 10 objects have to be eager loaded, for the 8 others the descriptor will be initialized.
Rather than storing the name of the descriptor, I suggest that we store the descriptor itself.
If we store the descriptor, we can just load the descriptors we need for eager creation.
This solution would be easier to persist (it is difficult to store a list of strings with JPA) and will not generate more db data as the descriptor is already stored in the db (with the descriptors map)
I have tried to make the modifications locally, all the unit tests succeed.
What do you think of this modification ?
Guillaume -
11. Re: basic persistence test
porcherg Aug 30, 2007 10:20 AM (in response to porcherg)"tom.baeyens@jboss.com" wrote:
postLoad in node should be removed. the maps must be derived from the list in a lazy fashion. only when they are actually used. and then they must be cached until the list changes. at that point, the map caches should be nulled.
In the current implementation, the map caches are updated when the lists are modified.
Should we keep this implementation or should the caches be nulled ?
Guillaume