tm4j-developers

[Tm4j-developers] Transactions and concurrent modification

[Andy P. <an...@il...>]

Hello,

I'm working on integrating use of TM4J and TMAPI into our application.
There's a couple of possible showstoppers though.

Firstly, the Hibernate implementations classes do a commit whenever a
suitable operation has completed, such as when a new topic is created, or an
occurence is added to a topic. What we'd like to do is control the commit
overselves and do it at a higher level. Thus a single transaction may
include multiple topics, associatons, occurences, etc. being created,
updated or deleted.

The other issue is that there doesn't seem to be a way of preventing
modification by more than 1 user at the same time. Using Hibernate's
optimistic lock mechanism would be one option here.

So I guess there's a couple of questions. Firstly, has anybody has to build
workarounds for these before, and secondly, is there any plan to put these
into TM4J?


Andy.

Re: [Tm4j-developers] Transactions and concurrent modification

[Kal A. <ka...@te...>]

Hi Andy,

There is a way to make more coarse-grained transactions with the
Hibernate backend. The relevant methods are:
TopicMapProvider.isTransactional() which returns true if the backend
supports transactions (currently only the Hibernate backend does).
TopicMapProvider.openTransaction() which starts a new transaction and
returns a org.tm4j.topicmap.ProviderTransaction instance.
TopicMapProvider.getOpenTransaction() which returns a handle to the
current transaction.
and then the methods of org.tm4j.topicmap.ProviderTransaction which you
can use to commit or rollback the transaction.

Currently nested transactions are not supported at all, but the
hibernate implementation only starts a new transaction for an API call
if one is not already started, so you should be able to do something
like:

txn = tm.getProvider().openTransaction();
// Do some stuff here
txn.commit(); // or txn.rollback()

This is all in the 0.9.x API BTW.

Hope this helps!

Cheers,

Kal

On Mon, 2004-05-17 at 15:14, Andy Peel wrote:
> Hello,
> 
> I'm working on integrating use of TM4J and TMAPI into our application.
> There's a couple of possible showstoppers though.
> 
> Firstly, the Hibernate implementations classes do a commit whenever a
> suitable operation has completed, such as when a new topic is created, or an
> occurence is added to a topic. What we'd like to do is control the commit
> overselves and do it at a higher level. Thus a single transaction may
> include multiple topics, associatons, occurences, etc. being created,
> updated or deleted.
> 
> The other issue is that there doesn't seem to be a way of preventing
> modification by more than 1 user at the same time. Using Hibernate's
> optimistic lock mechanism would be one option here.
> 
> So I guess there's a couple of questions. Firstly, has anybody has to build
> workarounds for these before, and secondly, is there any plan to put these
> into TM4J?
> 
> 
> Andy.
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Tm4j-developers mailing list
> Tm4...@li...
> https://lists.sourceforge.net/lists/listinfo/tm4j-developers
-- 
Kal Ahmed <ka...@te...>
techquila

RE: [Tm4j-developers] Transactions and concurrent modification

[Andy P. <an...@il...>]

> There is a way to make more coarse-grained transactions with the
> Hibernate backend. The relevant methods are:
> TopicMapProvider.isTransactional() which returns true if the backend
> supports transactions (currently only the Hibernate backend does).
> TopicMapProvider.openTransaction() which starts a new transaction and
> returns a org.tm4j.topicmap.ProviderTransaction instance.
> TopicMapProvider.getOpenTransaction() which returns a handle to the
> current transaction.
> and then the methods of org.tm4j.topicmap.ProviderTransaction which you
> can use to commit or rollback the transaction.

Excellent. Sorry, I'd misread the code, and just assumed that the commit
always happened, whereas it actually only commits if the method created the
new transaction itself. Cool.

> Currently nested transactions are not supported at all, but the
> hibernate implementation only starts a new transaction for an API call
> if one is not already started, so you should be able to do something
> like:
>
> txn = tm.getProvider().openTransaction();
> // Do some stuff here
> txn.commit(); // or txn.rollback()

I'd actually like to tell the TopicMapProvider to use a transaction that
already exists, so that my existing Hibernate transaction manager can create
a transaction for use in a service method that does some other stuff in my
app and then does the topic map stuff and then maybe does some other stuff
specific to my app. I can't see a way to do that at the moment, but I think
it'd be easy to add.

The other thing was concurrent modification preventation. I had a quick look
through the hbf.xml files and couldn't see a version column so I guess it
doesn't do optimistic locking.

Thanks Kal,


Andy.

RE: [Tm4j-developers] Transactions and concurrent modification

[Kal A. <ka...@te...>]

On Mon, 2004-05-17 at 17:27, Andy Peel wrote:
> > There is a way to make more coarse-grained transactions with the
> > Hibernate backend. The relevant methods are:
> > TopicMapProvider.isTransactional() which returns true if the backend
> > supports transactions (currently only the Hibernate backend does).
> > TopicMapProvider.openTransaction() which starts a new transaction and
> > returns a org.tm4j.topicmap.ProviderTransaction instance.
> > TopicMapProvider.getOpenTransaction() which returns a handle to the
> > current transaction.
> > and then the methods of org.tm4j.topicmap.ProviderTransaction which you
> > can use to commit or rollback the transaction.
> 
> Excellent. Sorry, I'd misread the code, and just assumed that the commit
> always happened, whereas it actually only commits if the method created the
> new transaction itself. Cool.
> 
> > Currently nested transactions are not supported at all, but the
> > hibernate implementation only starts a new transaction for an API call
> > if one is not already started, so you should be able to do something
> > like:
> >
> > txn = tm.getProvider().openTransaction();
> > // Do some stuff here
> > txn.commit(); // or txn.rollback()
> 
> I'd actually like to tell the TopicMapProvider to use a transaction that
> already exists, so that my existing Hibernate transaction manager can create
> a transaction for use in a service method that does some other stuff in my
> app and then does the topic map stuff and then maybe does some other stuff
> specific to my app. I can't see a way to do that at the moment, but I think
> it'd be easy to add.
> 
I think you would need to hack the code a bit to do that. But it should
all be localised in the HibernateProviderTransaction class I think.

> The other thing was concurrent modification preventation. I had a quick look
> through the hbf.xml files and couldn't see a version column so I guess it
> doesn't do optimistic locking.
> 

I didn't enable that, no. Without having a specific application in mind
its always a bit difficult to tell what should be turned on and what
should not. I guess that it should be possible for you to just hack the
configuration files and go with that - I don't think that any of the
code should need to change...

Cheers,

Kal

-- 
Kal Ahmed <ka...@te...>
techquila