Plugin framework: create transactions by annotation

[jri]

The plugin developer should not be required to create transactions imperatively. Instead she should create a transaction just by annotating a resource method. (A resource method is one with a method designator like @GET.) The DM Core should take provisions to "wrap" such an annotated method within a transaction automatically.

Current pattern (DM 4.3):

    import de.deepamehta.core.storage.spi.DeepaMehtaTransaction;

    public void aResourceMethod() {
        DeepaMehtaTransaction tx = dms.beginTx();
        try {
            ...
            tx.success();
        } catch (Exception e) {
            logger.warning("ROLLBACK!");
            throw new RuntimeException("Something failed", e);
        } finally {
            tx.finish();
        }
    }

New pattern:

    import de.deepamehta.core.service.Transactional;

    @Transactional
    public void aResourceMethod() {
        ...
    }

So, the new pattern would remove a reasonable amount of boilerplate code.

[Jörg Richter]

Core: create transactions by annotation (#698).

A plugin developer can create a transaction just by annotating a resource method. (A resource method is one with a method designator like @GET.) The DM Core takes provisions to "wrap" such an annotated method within a transaction automatically.

Example:

    import de.deepamehta.core.service.Transactional;

    @Transactional
    public void aResourceMethod() {
        ...
    }

See #698.

• Changeset: cec76d678f83832d3b460fd7a65d257fe73a5c22
• URL: ​https://github.com/jri/deepamehta/commit/cec76d678f83832d3b460fd7a65d257fe73a5c22

[Jörg Richter]

Adapt to Core change (@Transactional) (#698).

The DM distro plugins make use of the new @Transactional annotation.

PLUGIN DEVELOPMENT NOTES

Keep in mind that the Core Service methods (called via the dms object) do not create a transaction on its own anymore (but the corresponding resource methods of the Webservice plugin do). So, when your plugin encounters a NotInTransactionException exception just annotate your originally calling resource method with @Transactional. (A resource method is one with a method designator like @GET.)

Example:

import de.deepamehta.core.service.Transactional;

@Transactional
public void aResourceMethod() {
    ...
}

Note that the majority of your plugin methods are triggered originally by an HTTP request (directly or indirectly), that is a resource method. Annotating that resource method is sufficient. (In fact @Transactional annotations on non-resource methods are ignored.) Most plugins are not required to create a transaction imperatively anymore.

However, there are cases when your plugin methods are *not* triggered by a HTTP request. These cases include

• the allPluginsActive() event handler
• tests
• DM service calls from non-DM OSGi bundles

In these cases you're required to create the transaction imperatively, just as you did before:

    import de.deepamehta.core.storage.spi.DeepaMehtaTransaction;

    public void aMethod() {
        DeepaMehtaTransaction tx = dms.beginTx();
        try {
            ...
            tx.success();
        } catch (Exception e) {
            logger.warning("ROLLBACK!");
            throw new RuntimeException("Something failed", e);
        } finally {
            tx.finish();
        }
    }

Note: calling a @Transactional annotated resource method from another @Transactional annotated resource method is OK. No nested transaction will be created. (Nested transactions are not problematic anyway.) Keep in mind a transaction is only created for the resource method the original HTTP request is mapped to. So, typically there is a 1:1 relationship between transaction and HTTP request.

See #698.

• Changeset: aa93d6354d5145c33b12fd7fb3c87b66e715e454
• URL: ​https://github.com/jri/deepamehta/commit/aa93d6354d5145c33b12fd7fb3c87b66e715e454

[Jörg Richter]

Core: create transactions by annotation (#698).

A plugin developer can create a transaction just by annotating a resource method. (A resource method is one with a method designator like @GET.) The DM Core takes provisions to "wrap" such an annotated method within a transaction automatically.

Example:

    import de.deepamehta.core.service.Transactional;

    @Transactional
    public void aResourceMethod() {
        ...
    }

See #698.

• Changeset: cec76d678f83832d3b460fd7a65d257fe73a5c22
• URL: ​https://github.com/jri/deepamehta/commit/cec76d678f83832d3b460fd7a65d257fe73a5c22

[Jörg Richter]

Adapt to Core change (@Transactional) (#698).

The DM distro plugins make use of the new @Transactional annotation.

PLUGIN DEVELOPMENT NOTES

Keep in mind that the Core Service methods (called via the dms object) do not create a transaction on its own anymore (but the corresponding resource methods of the Webservice plugin do). So, when your plugin encounters a NotInTransactionException exception just annotate your originally calling resource method with @Transactional. (A resource method is one with a method designator like @GET.)

Example:

import de.deepamehta.core.service.Transactional;

@Transactional
public void aResourceMethod() {
    ...
}

Note that the majority of your plugin methods are triggered originally by an HTTP request (directly or indirectly), that is a resource method. Annotating that resource method is sufficient. (In fact @Transactional annotations on non-resource methods are ignored.) Most plugins are not required to create a transaction imperatively anymore.

However, there are cases when your plugin methods are *not* triggered by a HTTP request. These cases include

• the allPluginsActive() event handler
• tests
• DM service calls from non-DM OSGi bundles

In these cases you're required to create the transaction imperatively, just as you did before:

    import de.deepamehta.core.storage.spi.DeepaMehtaTransaction;

    public void aMethod() {
        DeepaMehtaTransaction tx = dms.beginTx();
        try {
            ...
            tx.success();
        } catch (Exception e) {
            logger.warning("ROLLBACK!");
            throw new RuntimeException("Something failed", e);
        } finally {
            tx.finish();
        }
    }

Note: calling a @Transactional annotated resource method from another @Transactional annotated resource method is OK. No nested transaction will be created. (Nested transactions are not problematic anyway.) Keep in mind a transaction is only created for the resource method the original HTTP request is mapped to. So, typically there is a 1:1 relationship between transaction and HTTP request.

See #698.

• Changeset: aa93d6354d5145c33b12fd7fb3c87b66e715e454
• URL: ​https://github.com/jri/deepamehta/commit/aa93d6354d5145c33b12fd7fb3c87b66e715e454

[Jörg Richter]

Core: create transactions by annotation (#698).

A plugin developer can create a transaction just by annotating a resource method. (A resource method is one with a method designator like @GET.) The DM Core takes provisions to "wrap" such an annotated method within a transaction automatically.

Example:

    import de.deepamehta.core.service.Transactional;

    @Transactional
    public void aResourceMethod() {
        ...
    }

See #698.

• Changeset: cec76d678f83832d3b460fd7a65d257fe73a5c22
• URL: ​https://github.com/jri/deepamehta/commit/cec76d678f83832d3b460fd7a65d257fe73a5c22

[Jörg Richter]

Adapt to Core change (@Transactional) (#698).

The DM distro plugins make use of the new @Transactional annotation.

PLUGIN DEVELOPMENT NOTES

Keep in mind that the Core Service methods (called via the dms object) do not create a transaction on its own anymore (but the corresponding resource methods of the Webservice plugin do). So, when your plugin encounters a NotInTransactionException exception just annotate your originally calling resource method with @Transactional. (A resource method is one with a method designator like @GET.)

Example:

import de.deepamehta.core.service.Transactional;

@Transactional
public void aResourceMethod() {
    ...
}

Note that the majority of your plugin methods are triggered originally by an HTTP request (directly or indirectly), that is a resource method. Annotating that resource method is sufficient. (In fact @Transactional annotations on non-resource methods are ignored.) Most plugins are not required to create a transaction imperatively anymore.

However, there are cases when your plugin methods are *not* triggered by a HTTP request. These cases include

• the allPluginsActive() event handler
• tests
• DM service calls from non-DM OSGi bundles

In these cases you're required to create the transaction imperatively, just as you did before:

    import de.deepamehta.core.storage.spi.DeepaMehtaTransaction;

    public void aMethod() {
        DeepaMehtaTransaction tx = dms.beginTx();
        try {
            ...
            tx.success();
        } catch (Exception e) {
            logger.warning("ROLLBACK!");
            throw new RuntimeException("Something failed", e);
        } finally {
            tx.finish();
        }
    }

Note: calling a @Transactional annotated resource method from another @Transactional annotated resource method is OK. No nested transaction will be created. (Nested transactions are not problematic anyway.) Keep in mind a transaction is only created for the resource method the original HTTP request is mapped to. So, typically there is a 1:1 relationship between transaction and HTTP request.

See #698.

• Changeset: aa93d6354d5145c33b12fd7fb3c87b66e715e454
• URL: ​https://github.com/jri/deepamehta/commit/aa93d6354d5145c33b12fd7fb3c87b66e715e454