Guicy discussion / Resource-Management / Transactions

[tbaum]

I'm using guice very extensively in different projects. Making Cdo Guice-friendly would be nice. In general I'm not sure if the Guice-binding should really be part of the Cdo-repo (there are other DI containers too :)

Why using custom injection ?

@CrystalMethod

Is there any particular reason to add the custom injection (using @CdoContext) IMHO in Guice you want to use the @Inject only - this would give the configured value from your injector/module. If you really need two different Instances you could use a @Named. I think the default injection is sufficient? But I didn't want to send a delete-classes PR without prior discussion:

Please have a look at this branch and here a code example: GuiceCdoManagerFactoryInjectionTest

Resource-Handling

@buschmais @DirkMahler

I would like to use a nice annotation which takes care about the transactions and resource-handling.
I'm using a tiny guice-module to make this easy look here: RollbackOnTest. This could be adopted very easily in CDO too. But for me the lifecycle is not completely clear:

• CdoManagerFactory (clear: infrastructure to get a manager)
• CdoManager kind of 'db-connection',
  • should this be shared or
  • closed/recreated every use?
• cdoManager.currentTransaction()
  • what happens if you call begin() twice, or
  • miss the 'commit/release'.
• what is the lifecycle of a object created in a tx?

  Transaction-Behaviour

@buschmais @DirkMahler

I like the transaction-behavior of neo4j. you always call the finish and mark a tx successful

Transaction tx = gdb.beginTx();
try {
  // some work  
  tx.success();
} 
finaly {
  tx.close();
}

this gets very handy with the auto-closeable.

try ( Transaction tx = gdb.beginTx() )  {
  // some work  
   tx.success();
} 

I would love to see this pattern in CDO too.

happy to see you in RL for some discussions or/and a beer :)

cheers, Thomas

[DirkMahler]

The semantics of CdoManagerFactory/CdoManager/CdoTransaction is (by intention) very close to the similar artifacts of JPA (and formerly JDO):

CdoManagerFactory

A factory to create CdoManagers and holding a configuration consisting of types, datastore properties, transaction attributes, datastore configuration etc. (i.e. CdoUnit, to be compared to a JPA Persistence Unit)

CdoManager

A concrete connection to the datastore (e.g. a JDBC connection).

CdoTransaction

Each CdoManager has an assigned CdoTransaction which allows starting and completing a transaction context (commit or rollback). It is only a thin wrapper around the transaction provided by the underlying datastore connection. In the future it could also wrap a managed transaction of a Java EE container. For a CdoManager there can be only one active transaction at the same time, i.e.

• beginning a new transaction while another transaction is active
• or committing/rolling back a non-active transaction must result in a CdoException. The same shall happen (but is not implemented yet) if a CdoManager is closed while there's still an active transaction.

Instance lifecycle

The lifecycle of instances is coupled to the CdoManager, i.e. an instance returned by a CdoManager (e.g. create(), find() or createQuery().execute()) can be used as long as the CdoManager is not closed. For this scope the CDO implementation will always return the reference to the same instance for subsequent calls on the CDO API or while traversing references between instances

• if the same datastore entity is referenced
• at least until the current transaction is completed (commit/rollback) and as long as the using application itself references the instance.

This means that an instance can be used in several subsequent transactions as long as the CdoManager is not closed. Note: There might be a change in the near future that only instances will be cached within the scope of an active transaction which have been modified (goal: optimize memory consumption for batch operations).

[DirkMahler]

Regarding AutoCloseable and CdoTransaction I'll make a proposal - it needs to be clarified how this fits with other potential datastores and integration into managed environments (e.g. Java EE, Spring).

[DirkMahler]

Related to #92