To make it clear and short:
I just want to make a cascading creation!
Hey its me again
I notice that all the data I added via da DataServiceTransaction-Class via my custom service is lost when I Stop and Start the tomcat again!!
I configured a tomcat within FlashBuilder(eclipse) and Start/Stop it from there!
Any Ideas? I know, I am doing something wrong!
1 person found this helpful
If using a Transactional data source with a model you to specify the hibernate.transaction.factory_class and hibernate.transaction.manager_lookup_class properties as appropriate for your server and then call DST with useJTA set to true.
Specifically for Tomcat, the below values should work:
Data Services does not support cascade operations on associations. You should save EntityB and then (in the same transaction) save EntityA.
thanks for your answer!
Does that mean, i just have to set these properties in my model if I want to create/update my datasource via the transaction-Api within my custom service?
How can I query the datasource,to know if i need a createItem for EntityB? I dont want to add EntityB with the same name property e.g?
When I set the properties like in the thread above(for tomcat), I cant deploy the model via the FlashBuilder! It says something like "Can't create Class of type "" ."(original Msg will be added soon )
Error creating and starting destinations while deploying model 'portal.Animal'.
Caused by: Cannot create class of type''.
(portal.Animal is a test-class)
I set the following properties in my model:
<item name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactor y</item> <item name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.JOTMTransacti onManagerLookup</item>
Has really nobody an idea for this problem?
Can you post a snippet of your model, specifically the model level DMS annotation where you have set the above properties?
With regards to whether EntityB is already saved or not, it is not possible to know without query the DB if the entity is already present. One common pattern that is followed in this case is to check if the ID is 0 (or some other pre-defined value) and then use that to infer that the item is unsaved,