DEV Community: EVan Wilson

Javascirpt basic Part 1

EVan Wilson — Wed, 23 Oct 2024 09:21:20 +0000

80%💥 of work time is wasted

EVan Wilson — Sat, 21 Sep 2024 12:18:19 +0000

In our daily work, you realize that most of your time is spent in communication without any progress in the actual work. This is incredibly frustrating, but it's a necessary evil we can't seem to escape from.

👧Talking with the UI designer: They only care if you've faithfully recreated their design.
👧Talking with the front-end developer: They only focus on whether you've got the field key type wrong.
🤷‍♂️Talking with the product manager: They only want to know when the feature will go live.

It's pure bullshit! When do I get time to actually code if I'm stuck in meetings all day? Are you kidding me?

So, Where Did We Go Wrong?

Is it that our communicated information has never aligned properly? This isn't something that can be solved by any project or product manager's organization alone. We genuinely need a unified communication mechanism. Every day, there's a massive pile of information that needs to be synced, especially API info, which is the most extensive and complex part of our development...

Is There a Solution?

I've envisioned an ideal approach, something like what's illustrated below:

I think this is the correct and scientific way to communicate. It revolves around API development and entails collaborative communication among different participants to address asymmetric API information. From Product Requirements -> API Design -> Share API documentation (including a mockURL) -> API Debug -> API Testing -> Deploy, as long as the requirements remain unchanged and the API design is agreed upon, I won’t have to waste 80% of my time on communication.

How to Implement This Idea

This plan looks perfect on paper! But how can we execute it effectively? I feel the product manager might not follow my lead. So, I tried to find a tool to solve this problem. Jira (for project management), Postman (for API management), and others didn’t quite fit until I found this tool: EchoAPI!

I explored EchoAPI's product features and attempted to utilize it to complete this work mechanism:

This is my vision. I want to use this method to reduce communication barriers in development. Hopefully, this approach is useful for all of us and helps us reclaim our 80% of the time.

Javascript operators for Beginners

EVan Wilson — Fri, 20 Sep 2024 12:07:25 +0000

1.JavaScript Basic

2.Welcome to join in and contribute!

welcome to join in and contribute! Click the link below to add more:👇👇👇 [https://workspace.echoapi.com/user/invite?invitation_code=U336b1bb65c02000].

You can directly add your scripts in the "Processing Script" section under the "Post-response" tab. 🐋
Once you're done, hit "send" to see if everything checks out.🦭

DayJS Functions for Beginners: Contributions Welcome!

EVan Wilson — Thu, 19 Sep 2024 12:38:28 +0000

I've compiled a list of commonly used DayJS Functions to help beginners find what they need quickly and easily. Experienced developers are welcome to join in and contribute! Click the link below to add more:👇👇👇 [https://workspace.echoapi.com/user/invite?invitation_code=U336b1bb65c02000].

You can directly add your scripts in the "Processing Script" section under the "Post-response" tab. 🐋
Once you're done, hit "send" to see if everything checks out.🦭

Here's a quick diagram to guide you:🦕

PostgreSQL Insights: Understanding MVCC in Transactions

EVan Wilson — Wed, 18 Sep 2024 10:50:36 +0000

PostgreSQL Insights: Understanding MVCC in Transactions

0. Introduction

This article delves into the Multi-Version Concurrency Control (MVCC) mechanism commonly implemented in transaction modules. It explores the advantages and disadvantages of MVCC, along with its specific implementation in PostgreSQL.

1. Introduction to MVCC

MVCC (Multi-Version Concurrency Control) is a method utilized in database management systems for handling concurrent access. Traditional concurrency control often relies on locking, ensuring that only one transaction can modify data at a time. However, this approach can lead to reduced concurrency and performance bottlenecks, especially in high-concurrency scenarios. MVCC addresses some limitations of the traditional locking mechanism by maintaining multiple versions of data. Each transaction sees a specific version, allowing read and write operations to execute without interfering with each other. Essentially, when a modification is made, a new version of the data is created instead of altering the original data directly. Other transactions can still access the old data, enhancing concurrency. Despite its benefits, MVCC can consume more memory due to multiple versions, particularly in high-concurrency environments.

2. Common Implementations of MVCC

There are two prevalent approaches to implementing MVCC:

Backup Before Modifying: Before modifying the old data, it is backed up to a separate space while the new data is written. Other transactions can read from this backup space, such as the rollback segment in MySQL's InnoDB engine.
Insert Instead of Modify: Instead of modifying the existing data, new data is inserted.

Both methods achieve MVCC but require additional space. Comparing the two, the second method simplifies transaction rollback and avoids running out of backup space. The first method, however, simplifies cleanup and prevents data scans from increasing data reads. PostgreSQL adopts the second approach, implementing MVCC through insertion.

3. MVCC Implementation in PostgreSQL

3.1 Visibility Determination

For MVCC to work, the concept of data versioning must be defined. PostgreSQL's definition is as follows:

typedef struct HeapTupleFields {
    TransactionId t_xmin;    /* inserting xact ID */
    TransactionId t_xmax;    /* deleting or locking xact ID */

    union {
        CommandId  t_cid;    /* inserting or deleting command ID, or both */
        TransactionId t_xvac;  /* old-style VACUUM FULL xact ID */
    } t_field3;
} HeapTupleFields;

struct HeapTupleHeaderData {
    union {
        HeapTupleFields t_heap;
        DatumTupleFields t_datum;
    } t_choice;

    ItemPointerData t_ctid;    /* current TID of this or newer tuple (or a speculative insertion token) */
    ...
};

In this structure, each tuple's header stores the transaction ID for data insertion (t_xmin) and deletion or update (t_xmax). A zero t_xmax value indicates that the data hasn't been deleted or updated. These values are immutable once set.

Consider an example where a record with a=2 and b=2 was inserted by a transaction with ID 10 (t_xmin=10). Initially, t_xmax=0, meaning it hasn't been deleted or updated. An UPDATE statement changes a to 6, setting t_xmax to 11 (indicating that transaction 11 deleted it), and creates a new record (without modifying the original one). Although two records exist, visibility must be determined using transaction snapshots and commit logs.

PostgreSQL uses snapshots to determine which transactions are currently active. A transaction's updates and writes are invisible to others if it hasn't completed. Snapshot data structure:

typedef struct SnapshotData {
    SnapshotSatisfiesFunc satisfies;  /* tuple test function */
    TransactionId xmin;      /* all XID < xmin are visible */
    TransactionId xmax;      /* all XID >= xmax are invisible */

    TransactionId *xip;
    uint32 xcnt;      /* # of xact IDs in xip[] */

    TransactionId *subxip;
    int32 subxcnt;    /* # of xact IDs in subxip[] */
    bool suboverflowed;  /* has the subxip array overflowed? */

    bool takenDuringRecovery;  /* recovery-shaped snapshot? */
    bool copied;      /* false if it's a static snapshot */

    CommandId curcid;      /* in my xact, CID < curcid are visible */

    uint32 speculativeToken;

    uint32 active_count;  /* refcount on ActiveSnapshot stack */
    uint32 regd_count;    /* refcount on RegisteredSnapshots */
    pairingheap_node ph_node;  /* link in the RegisteredSnapshots heap */

    TimestampTz whenTaken;    /* timestamp when snapshot was taken */
    XLogRecPtr lsn;      /* position in the WAL stream when taken */
} SnapshotData;

Transactions with IDs less than xmin are visible; those with IDs greater than or equal to xmax are invisible. Transactions between xmin and xmax might still be active, requiring an array (xip) to track them. If found in xip, the transaction is ongoing and invisible.

When fetching data, it first checks the snapshot to see if the transaction is complete. If not, it's invisible. If complete, it checks whether it was committed or aborted by querying the commit log (CLOG). For performance, PostgreSQL also employs tuple header flags to reduce CLOG queries.

3.2 Commit/Abort

In PostgreSQL, a transaction can end in one of two states: Commit or Abort:

Commit: Writes to the Write-Ahead Log (WAL) and CLOG on commit. Post-commit, the transaction's changes are visible to others.
Abort: Writes to WAL and CLOG on abort. Post-abort, the transaction's changes remain invisible to others.

How to Implement Batch Message Consumption with RocketMQ in Spring Boot

EVan Wilson — Fri, 13 Sep 2024 13:27:07 +0000

1. Adding Dependencies

First, add the necessary dependencies to your pom.xml file:

<!-- RocketMQ Spring Boot dependency for Spring Boot 3 -->
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-spring-boot-starter</artifactId>
    <version>2.3.1</version>
    <exclusions>
        <exclusion>
            <groupId>org.apache.rocketmq</groupId>
            <artifactId>rocketmq-client</artifactId>
        </exclusion>
    </exclusions>
</dependency>

<!-- Dependency compatible with MQ cluster version 5.3.0 -->
<dependency>
    <groupId>org.apache.rocketmq</groupId>
    <artifactId>rocketmq-client</artifactId>
    <version>5.3.0</version>
</dependency>

2. Configuration File `bootstrap.yaml`

Configure your RocketMQ settings in the bootstrap.yaml file:

rocketmq:
  name-server: 192.168.1.1:9876;192.168.1.2:9876;192.168.1.3:9876 # Replace with actual NameServer addresses
  consumer:
    group: consume-group-test
    access-key: access # Configure if ACL is used
    secret-key: secret
    consume-message-batch-max-size: 50  # Max messages per batch
    pull-batch-size: 100  # Max messages pulled from Broker
  topics:
    project: "group-topic-1"
  groups:
    project: "consume-group-1"  # Use different groups for different business processes

3. Configuration Class `MqConfigProperties`

Create the configuration class MqConfigProperties:

import org.apache.rocketmq.spring.autoconfigure.RocketMQProperties;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
import lombok.Data;

import java.io.Serializable;

/**
 * RocketMQ Configuration Class
 */
@Data
@Component
@ConfigurationProperties(prefix = "rocketmq")
public class MqConfigProperties implements Serializable {

    private static final long serialVersionUID = 1L;

    @Autowired
    private RocketMQProperties rocketMQProperties;

    private TopicProperties topics;
    private GroupProperties groups;

    /**
     * Topic Configuration Class
     */
    @Data
    public static class TopicProperties implements Serializable {
        private static final long serialVersionUID = 1L;
        private String project;
    }

    /**
     * Consumer Group Configuration Class
     */
    @Data
    public static class GroupProperties implements Serializable {
        private static final long serialVersionUID = 1L;
        private String project;
    }
}

4. Implementing the Consumer Code

Create the consumer class UserConsumer:

import com.alibaba.fastjson2.JSONObject;
import org.apache.rocketmq.client.consumer.DefaultMQPushConsumer;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyContext;
import org.apache.rocketmq.client.consumer.listener.ConsumeConcurrentlyStatus;
import org.apache.rocketmq.client.consumer.listener.MessageListenerConcurrently;
import org.apache.rocketmq.client.consumer.rebalance.AllocateMessageQueueAveragely;
import org.apache.rocketmq.common.consumer.ConsumeFromWhere;
import org.apache.rocketmq.common.message.MessageExt;
import org.apache.rocketmq.remoting.RPCHook;
import org.apache.rocketmq.spring.support.RocketMQUtil;
import org.springframework.context.ApplicationContext;
import org.springframework.context.SmartLifecycle;
import org.springframework.stereotype.Component;
import lombok.extern.slf4j.Slf4j;

import javax.annotation.Resource;
import java.util.List;

/**
 * Batch Consumer Implementation
 */
@Component
@Slf4j
public class UserConsumer implements SmartLifecycle {

    @Resource
    private MqConfigProperties mqConfigProperties;

    @Resource
    private ApplicationContext applicationContext;

    private volatile boolean running;
    private DefaultMQPushConsumer consumer;

    @Override
    public void start() {
        if (isRunning()) {
            throw new IllegalStateException("Consumer is already running");
        }
        initConsumer();
        setRunning(true);
        log.info("UserConsumer started successfully.");
    }

    @Override
    public void stop() {
        if (isRunning() && consumer != null) {
            consumer.shutdown();
            setRunning(false);
            log.info("UserConsumer stopped.");
        }
    }

    @Override
    public boolean isRunning() {
        return running;
    }

    private void setRunning(boolean running) {
        this.running = running;
    }

    private void initConsumer() {
        String topic = mqConfigProperties.getTopics().getProject();
        String group = mqConfigProperties.getGroups().getProject();
        String nameServer = mqConfigProperties.getRocketMQProperties().getNameServer();
        String accessKey = mqConfigProperties.getRocketMQProperties().getConsumer().getAccessKey();
        String secretKey = mqConfigProperties.getRocketMQProperties().getConsumer().getSecretKey();

        RPCHook rpcHook = RocketMQUtil.getRPCHookByAkSk(applicationContext.getEnvironment(), accessKey, secretKey);
        consumer = rpcHook != null
                ? new DefaultMQPushConsumer(group, rpcHook, new AllocateMessageQueueAveragely())
                : new DefaultMQPushConsumer(group);

        consumer.setNamesrvAddr(nameServer);
        consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_LAST_OFFSET);
        consumer.setConsumeMessageBatchMaxSize(100);  // Set the batch size for consumption
        consumer.subscribe(topic, "*");
        consumer.setMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                log.info("Received {} messages", msgs.size());
                for (MessageExt message : msgs) {
                    String body = new String(message.getBody());
                    log.info("Processing message: {}", body);
                    User user = JSONObject.parseObject(body, User.class);
                    processUser(user);
                }
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });

        consumer.start();
        log.info("UserConsumer initialized with topic [{}] and group [{}].", topic, group);
    }

    private void processUser(User user) {
        log.info("Processing user with ID: {}", user.getId());
        // Handle user-related business logic
    }
}

5. Producer Example Code

To produce batch messages, you can use the following UserProducer class:

import org.apache.rocketmq.client.producer.DefaultMQProducer;
import org.apache.rocketmq.common.message.Message;
import java.util.ArrayList;
import java.util.List;

public class UserProducer {

    private DefaultMQProducer producer;

    public void sendBatchMessages(List<User> users, String topic) {
        List<Message> messages = new ArrayList<>();
        for (User user : users) {
            messages.add(new Message(topic, JSONObject.toJSONString(user).getBytes()));
        }
        try {
            producer.send(messages);
        } catch (Exception e) {
            log.error("Error sending batch messages", e);
        }
    }
}

6. Additional Optimization Suggestions

Performance Optimization: You can adjust the size of the consumer thread pool. By default, it's set to consumeThreadMin=20 and consumeThreadMax=20. In high-concurrency scenarios, increasing the thread pool size can enhance performance.
Error Handling: When consumption fails, be cautious with RECONSUME_LATER to avoid infinite retry loops. Set a maximum retry count based on your business requirements.
Tenant Isolation: Use different groups for different business modules to avoid consuming data from the wrong group. This is especially crucial in production environments.

How to Correct Yum Baseurl Issues on CentOS 7

EVan Wilson — Thu, 12 Sep 2024 13:37:19 +0000

_CentOS 7 Yum Error: Cannot Find a Valid Baseurl for Repo:base/7/x86_64_

Hey folks,

Encountering the error cannot find a valid baseurl for repo:base/7/x86_64 can be quite frustrating, especially when you're trying to get things done on CentOS 7. This issue generally occurs because Yum can't find or access the repository URLs it needs. Let's break down a few ways to troubleshoot and fix this problem, step by step.

Error Explanation

This error usually happens when Yum can't locate or access repository sources, making it unable to function properly. It's common on CentOS 7 and can typically be resolved by checking a few things like network connectivity, DNS settings, and Yum repository configurations.

Step-by-Step Solutions to Fix the Error

Method 1: Check Network Connectivity

First things first, make sure your system is connected to the internet because Yum needs to reach remote repositories to download packages.

Verify Network Connection You can check if your system can access external websites by running:

   ping -c 4 google.com

If it doesn't ping successfully, you might have a network configuration issue. You can restart the network service with:

   sudo systemctl restart network

Method 2: Check DNS Settings

If your network connection is fine but you still can't access repositories, the issue might be with your DNS settings.

Update DNS Configuration Edit the /etc/resolv.conf file to ensure it contains valid DNS servers like Google's public DNS:

   sudo nano /etc/resolv.conf

Add the following lines:

   nameserver 8.8.8.8
   nameserver 8.8.4.4

Save the file and exit.

Check Domain Name Resolution Run another ping test to verify:

   ping -c 4 google.com

Method 3: Check Yum Repository Configuration

If the network connection and DNS settings are fine, the problem might be with your Yum repository configuration.

Update Yum Repository Sources Back up your current Yum config files:

   sudo cp -r /etc/yum.repos.d /etc/yum.repos.d.backup

Edit or replace the repository configuration files. For example, open /etc/yum.repos.d/CentOS-Base.repo:

   sudo nano /etc/yum.repos.d/CentOS-Base.repo

Ensure the baseurl and gpgcheck settings are correct. You can manually edit this file or use a reliable mirror source.

Example: Using Official CentOS Mirror Config

   [base]
   name=CentOS-$releasever - Base
   baseurl=http://mirror.centos.org/centos/$releasever/os/$basearch/
   gpgcheck=1
   gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

   [updates]
   name=CentOS-$releasever - Updates
   baseurl=http://mirror.centos.org/centos/$releasever/updates/$basearch/
   gpgcheck=1
   gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

   [extras]
   name=CentOS-$releasever - Extras
   baseurl=http://mirror.centos.org/centos/$releasever/extras/$basearch/
   gpgcheck=1
   gpgkey=http://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-7

Save and exit the file.

Clear and Rebuild Yum Cache

   sudo yum clean all
   sudo yum makecache
   sudo yum update

Summary

The cannot find a valid baseurl for repo:base/7/x86_64 error is often due to issues with network connectivity, DNS settings, or Yum repository configuration. By checking and fixing these aspects, or by using reliable mirror sources , you can solve this problem efficiently. Hope this guide helps you get Yum back up and running smoothly. If you have any questions or further issues, feel free to drop a comment!

Happy coding!

Spring Boot: How to Solve Cross-Origin Issues

EVan Wilson — Wed, 11 Sep 2024 13:20:05 +0000

Cross-Origin Issue Description

You might encounter the following error message:

been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource

This error indicates that a request to a certain address has been blocked by the CORS protocol because the Access-Control-Allow-Origin header is missing from the resource.

Analyzing Cross-Origin Issues

The root cause of cross-origin issues is that browsers, for security reasons, restrict access to resources outside the current site.

For example, consider a website hosted at http://127.0.0.1:8080/ with a certain page. If you access resources from the same site, there are no restrictions. But if you try to access resources from a different site (e.g., http://127.0.0.1:8081), the browser will block the request.

Note: We consider protocol, domain, and port as part of defining a "same-origin."

Elements with a src attribute, like img and script tags, are not subject to this restriction.

Historically, when front-end and back-end were not separate, pages and request interfaces existed under the same domain and port. Browsers would then allow requests from a page hosted at one domain to request resources from the same domain.

For example, http://127.0.0.1:8080/index.html can freely request http://127.0.0.1:8080/a/b/c/userLit.

Nowadays, with the front-end and back-end separated into different applications, this isn't allowed and will trigger CORS issues.

What is Origin and Cross-Origin?

Origin (or source) consists of the protocol, domain, and port number.

A URL is composed of protocol, domain, port, and path. Two URLs are considered "same-origin" if their protocol, domain, and port are all identical. Any difference in any of these three elements constitutes a cross-origin request.

Consider cross-origin comparisons for https://www.baidu.com/index.html:

URL	Cross-Origin	Reason
https://www.baidu.com/more/index.html	No	Same protocol, domain, and port
https://map.baidu.com/	Yes	Different domain
http://www.baidu.com/index.html	Yes	Different protocol
https://www.baidu.com:81/index.html	Yes	Different port

What is the Same-Origin Policy?

The Same-Origin Policy is a fundamental browser security feature. Without it, the normal functionality of browsers could be at risk. Web architecture heavily depends on this policy, and browsers implement it to ensure security.

The Same-Origin Policy includes:

DOM Same-Origin Policy: Prevents DOM manipulation of different origin pages. Applies mainly to cross-origin iframe scenarios where different domains' iframes can't access each other.
XMLHttpRequest Same-Origin Policy: Prohibits HTTP requests to different origins using XHR objects.

Solving Cross-Origin Issues in Spring Boot

1. Creating a Filter to Handle CORS

In a project where the front-end and back-end are deployed separately, addressing CORS is crucial. Cookies are used to store user login information, and Spring interceptors manage permissions. Issues arise when the interceptor and CORS are processed in the wrong order, causing a CORS error.

An HTTP request first goes through the filter before reaching the servlet and then the interceptor. To ensure CORS processing occurs before authorization interception, we can place the CORS configuration in a filter.

@Configuration
public class CorsConfig {

    @Bean
    public CorsFilter corsFilter() {
        CorsConfiguration corsConfiguration = new CorsConfiguration();
        corsConfiguration.addAllowedOrigin("*");
        corsConfiguration.addAllowedHeader("*");
        corsConfiguration.addAllowedMethod("*");
        corsConfiguration.setAllowCredentials(true);

        UrlBasedCorsConfigurationSource urlBasedCorsConfigurationSource = new UrlBasedCorsConfigurationSource();
        urlBasedCorsConfigurationSource.registerCorsConfiguration("/**", corsConfiguration);
        return new CorsFilter(urlBasedCorsConfigurationSource);
    }
}

2. Configuring CORS in WebMvcConfigurer

While JSONP can address cross-origin issues on the front-end, it only supports GET requests, which is limiting in RESTful applications. Instead, you can handle cross-origin requests with Cross-Origin Resource Sharing (CORS) on the back-end. This solution is not unique to Spring Boot and has been used in traditional SSM frameworks. You configure it by implementing the WebMvcConfigurer interface and overriding the addCorsMappings method.

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/**")
                .allowedOrigins("*")
                .allowCredentials(true)
                .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS")
                .maxAge(3600);
    }
}

3. Configuring CORS in Controller

You can enable CORS for specific controller methods by adding the @CrossOrigin annotation to the @RequestMapping annotation. By default, @CrossOrigin allows all origins and HTTP methods specified in @RequestMapping.

@RestController
@RequestMapping("/account")
public class AccountController {

    @CrossOrigin
    @GetMapping("/{id}")
    public Account retrieve(@PathVariable Long id) {
        // ...
    }

    @DeleteMapping("/{id}")
    public void remove(@PathVariable Long id) {
        // ...
    }
}

Understanding @CrossOrigin Parameters：

@CrossOrigin without parameters allows all URLs to access.
@CrossOrigin(origins = "http://127.0.0.1:8080") restricts access to the specified URL.
This annotation can be used on classes or methods.
The value or origins attribute specifies allowed URLs.
maxAge indicates the maximum age in seconds for the preflight request cache.
allowCredentials indicates if credentials (cookies) are allowed. Default is false.
allowedHeaders specifies allowed request headers.
methods specifies allowed request methods, default being GET, POST, HEAD.

Reasons @CrossOrigin Might Not Work

Spring MVC version must be 4.2 or higher to support @CrossOrigin.
Incorrect requests might appear as cross-origin issues due to improper server response.
If adding @CrossOrigin above the Controller annotation still results in issues, one possible fix is to specify the HTTP methods in @RequestMapping.

Example:

@CrossOrigin
@RestController
public class PersonController {

    @RequestMapping(method = RequestMethod.GET)
    public String add() {
        // some code
    }
}

DEV Community: EVan Wilson

Javascirpt basic Part 1

80%💥 of work time is wasted

So, Where Did We Go Wrong?

Is There a Solution?

How to Implement This Idea

Javascript operators for Beginners

1.JavaScript Basic

2.Welcome to join in and contribute!

DayJS Functions for Beginners: Contributions Welcome!

PostgreSQL Insights: Understanding MVCC in Transactions

PostgreSQL Insights: Understanding MVCC in Transactions

0. Introduction

1. Introduction to MVCC

2. Common Implementations of MVCC

3. MVCC Implementation in PostgreSQL

3.1 Visibility Determination

3.2 Commit/Abort

How to Implement Batch Message Consumption with RocketMQ in Spring Boot

1. Adding Dependencies

2. Configuration File bootstrap.yaml

3. Configuration Class MqConfigProperties

4. Implementing the Consumer Code

5. Producer Example Code

6. Additional Optimization Suggestions

How to Correct Yum Baseurl Issues on CentOS 7

Error Explanation

Step-by-Step Solutions to Fix the Error

Method 1: Check Network Connectivity

Method 2: Check DNS Settings

Method 3: Check Yum Repository Configuration

Summary

Spring Boot: How to Solve Cross-Origin Issues

Cross-Origin Issue Description

Analyzing Cross-Origin Issues

What is Origin and Cross-Origin?

What is the Same-Origin Policy?

Solving Cross-Origin Issues in Spring Boot

1. Creating a Filter to Handle CORS

2. Configuring CORS in WebMvcConfigurer

3. Configuring CORS in Controller

Reasons @CrossOrigin Might Not Work

2. Configuration File `bootstrap.yaml`

3. Configuration Class `MqConfigProperties`